RFR: 7903912: JMH: Pad using a mix of bytes and longs [v2]

[Aleksey Shipilev]

On Tue, 17 Dec 2024 23:41:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Using a mix of bytes and longs we should get the gap-filling effect described in https://shipilev.net/jvm/objects-inside-out/#_observation_hierarchy_tower_padding_trick_collapse_in_jdk_15 while reducing size of generated code by roughly 20%:
>> 
>> 
>> 864772  jmh-samples/target/jmh-samples-1.38-SNAPSHOT.jar
>> 490531  jmh-samples/target/jmh-samples-1.38-SNAPSHOT-sources.jar
>> 
>> 684383 jmh-samples/target/jmh-samples-1.38-SNAPSHOT.jar
>> 399758 jmh-samples/target/jmh-samples-1.38-SNAPSHOT-sources.jar
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into byte_long_padding
>  - Adjust hierarchical padding in static code
>  - Superficial comment change to trigger pre-integration tests
>  - Pad with a mix of bytes and longs

All right, I have convinced myself that with current JDK 15+ layouter we can only have [0..7] bytes total gaps when the max allocation size is 8 bytes. I did this by building the simulator that tracks the possible layouter state, and the full state graph says it never breaks out to the state with larger than 7 bytes of gaps: https://github.com/openjdk/jmh/compare/master...shipilev:jmh:gaps-simulator. (I should put this sim somewhere in JOL...)

The only caveat I see is interaction with Valhalla years later. It looks like the current max alignment in Valhalla prototype is the alignment of the largest component in inline type (64 bits max, in other words), but I suspect at some point it would be rectified to allow 128 bits alignment for the entire inlined fields block, in case hardware allows atomic accesses of that size. Simulator says that with the max allocation size of 16 bytes, the total size of gaps is never larger than 15 bytes.

So, for future-proofing, I think we are good with 16 booleans and 30 longs.

-------------

PR Comment: https://git.openjdk.org/jmh/pull/147#issuecomment-2575372915