P4
Post JEP 387, a metaspace arena has a freeblock management unit whose purpose is to manage stray metaspace blocks (e.g. prematurely released MetaspaceObj instances). See `metaspace/freeBlocks.hpp`.
These blocks are managed in a binary tree (big blocks, `blockTree.hpp`) or in a staggered freelist (small blocks, `binList.hpp`).
If a block is retrieved from that unit, and it is much larger than what the caller actually wanted, it is split into two blocks, with the remainder block being re-added to the structure for later use (see `FreeBlocks::remove_block(size_t requested_word_size)`). That routine is wrong since it does not take the metaspace allocation alignment requirements into account: the trailing remainder block, which is re-added to the freeblocks structure, may have an unaligned start address.
Metaspace alignment is 64-bit, and all metaspace allocation routines and sizes deal with word sizes. So as of now, this is only a problem for 32-bit platforms. On 32-bit, one could get memory back which is just 32-bit aligned, not 64-bit as it should be, and if the MetaspaceObj occupying this memory holds 64-bit members, accessing them would result in unaligned accesses.
Probably hidden on x86, so maybe this is just a problem for arm32 atm.
However, with Lilliput, I experiment with much larger alignments for Klass structures, and there we run quickly into this error on all platforms.
These blocks are managed in a binary tree (big blocks, `blockTree.hpp`) or in a staggered freelist (small blocks, `binList.hpp`).
If a block is retrieved from that unit, and it is much larger than what the caller actually wanted, it is split into two blocks, with the remainder block being re-added to the structure for later use (see `FreeBlocks::remove_block(size_t requested_word_size)`). That routine is wrong since it does not take the metaspace allocation alignment requirements into account: the trailing remainder block, which is re-added to the freeblocks structure, may have an unaligned start address.
Metaspace alignment is 64-bit, and all metaspace allocation routines and sizes deal with word sizes. So as of now, this is only a problem for 32-bit platforms. On 32-bit, one could get memory back which is just 32-bit aligned, not 64-bit as it should be, and if the MetaspaceObj occupying this memory holds 64-bit members, accessing them would result in unaligned accesses.
Probably hidden on x86, so maybe this is just a problem for arm32 atm.
However, with Lilliput, I experiment with much larger alignments for Klass structures, and there we run quickly into this error on all platforms.