Metaspace allocations are aligned - by metaspace itself - to word size. Their size is also word-aligned, due to the simple fact that the allocation interface is word-sized. Their size is also at least two words, which has to do with the fact how we manage prematurely returned allocations.

Independent from what metaspace does, currently childs of MetasapceObj go through some pain to align their allocation sizes to words.

This is a noop (align_metadata_size() aligns to 1). I read through the review history of JDK-8145628, and I understand the motivation for it. But I think this is unnecessary, because the callers should not care what alignments and corrections metaspace applies to the requested size. Strictly speaking, there should be as little metaspace specific knowledge in the upper layers as possible.

Note that if caller cares for alignment of the *start address* due to the alignment requirements of the non-static members, we could easily add alignment-specific interfaces (like old-style hotspot arenas offers with Amalloc_X).

There was an argument in the review thread for 8145628 that some callers need this to estimate overhead of allocations. I don't think this is good design though. The overhead for an allocation is more complex than just the padding of the returned allocation; trying to proactively outguess the underlying allocator is fragile. No-one would try that with malloc :).

And at the moment this guessing game is already a bit broken because the callers do not know about the minimal (2 word) allocation size.

I propose to simplify this. Lets not try to guess metaspace overhead and lets keep knowledge about metaspace internals inside metaspace.

This makes it possible to freely experiment with the underlying implementation (e.g. I am experimenting with having class space allocs 16 byte aligned - and only class space - to get a 64g narrow class pointer range).