P4
Today, Metaspace uses a single global value for allocation alignment (which happens to be 64-bit on both 32- and 64-bit platforms).
This value was choosen because it allows us to store metadata containing 64-bit POD with correct alignment. Note that malloc alignment is usually higher, since it must allow for native 80- or 128-bit data to be stored with the correct alignment. But we know that our MetaspaceObj childs never contain those variables.
However, it would be more flexible if alignment was handled at arena level, so that we could have different parts of Metaspace using different alignment values. That way we could
- use a smaller alignment in cases where we want tighter packing
- set e.g. LogKlassAlignmentInBytes to a higher value without paying a steep price in memory: currently, it would increase metaspace alignment for all data, not only Klass strucutures, and since most metadata are very fine-granular this would cause a lot of memory waste.
This change is inspired by work in project Lilliput, where LogKlassAlignmentInBytes is set to a much higher value for reasons [1], but I think it makes sense in the mainline JDK too. As a benefit, it would reduce delta to upstream in Lilliput.
[1] https://github.com/openjdk/lilliput/pull/13
This value was choosen because it allows us to store metadata containing 64-bit POD with correct alignment. Note that malloc alignment is usually higher, since it must allow for native 80- or 128-bit data to be stored with the correct alignment. But we know that our MetaspaceObj childs never contain those variables.
However, it would be more flexible if alignment was handled at arena level, so that we could have different parts of Metaspace using different alignment values. That way we could
- use a smaller alignment in cases where we want tighter packing
- set e.g. LogKlassAlignmentInBytes to a higher value without paying a steep price in memory: currently, it would increase metaspace alignment for all data, not only Klass strucutures, and since most metadata are very fine-granular this would cause a lot of memory waste.
This change is inspired by work in project Lilliput, where LogKlassAlignmentInBytes is set to a much higher value for reasons [1], but I think it makes sense in the mainline JDK too. As a benefit, it would reduce delta to upstream in Lilliput.
[1] https://github.com/openjdk/lilliput/pull/13