Discussion: How to get to single object header layout

[coleen.phillimore at oracle.com]

Roman,

Thank you for sending out the plan for getting to a single object header 
layout.  See below:

On 2/26/25 1:52 PM, Kennke, Roman wrote:
> (2nd attempt at sending this. If you receive the other attempt, please ignore it.)
>
> This is a follow-up to discussions that we had at the OpenJDK Committers Workshop earlier this month. I have been asked to come up with a detailed schedule of how I envision to make compact object headers aka Project Lilliput the default and one and only header layout in HotSpot, and post it here for wider discussion. The goal is to get to a consensus and prepare the various HotSpot contributors for what may come and when. In particular, I am aware that other, potentially conflicting changes are in the pipeline too (looking at Valhalla, possibly other projects, too?), which we should coordinate, not only in terms of code, but also in terms of reviewer/testing resources.
>
> We agreed at the OCW that we should make the current 8-byte-headers the default object header layout first, and only then build 4-byte-headers on top of that. We also agreed that we want as few flags permutations as possible (if it were me, I would vote for having no new flags at all, and have new implementations replace old implementations, but I can see the operational usefulness of having a fallback available if something unexpected goes wrong.)
>
> Many of the proposed changes are ‘only’ various progressions of flags moving from new/experimental to non-experimental to default to deprecated and obsoleted. The bulk of code changes would be in JDK 27, when Lilliput 2 hits the repos (which isn't as scary as Lilliput 1, which replaced the whole locking subsystem), and the current 12-byte headers are removed.
>
> Please let me know what you think, how we can make this work, and especially whatever concerns you may have.
>
> JDK 25:
> - 8350272: Deprecate UseCompressedClassPointers for removal
> - 8350457: Support Compact Object Headers as product option

I filed 8350457 to collect information that we need to decide to move 
UseCompactObjectHeaders out of Experimental mode.  See the bug for more 
details: https://bugs.openjdk.org/browse/JDK-8350457

One of the first and most important things we need is to show that there 
is a performance improvement either in throughput or density for this 
change.  I assigned this to you, but I'm also currently in the process 
of running our internal benchmarks to determine the impact of this 
change and I'll post analysis there when I have more details.  Also we 
need some fresh performance results that you are seeing.  If the option 
is a product option, we need to tell people why they want to use this 
option.  There may be some performance regressions for some applications 
with UCCP so we need to show to overall improvements in other types of 
applications, and or mitigate the regressions.

The remaining tasks for JDK 26 and beyond depend on what we find as a 
result of this step, including L2, whose performance numbers would be 
interesting to see as well.

Thank you,
Coleen

>
> JDK 26:
> - 8346011: [Lilliput] Compact Full-GC Forwarding (required for UCCP removal, pre-req for L2)
> - Obsolete +/-UseCompressedClassPointers
> - Make +UseCompactObjectHeaders on-by-default
> - Deprecate -UseCompactObjectHeaders
>
> JDK 27:
> - Obsolete -UseCompactObjectHeaders
> - 8320761: [Lilliput] Implement compact identity hashcode (alternative code path to L1, under new experimental flag, e.g. +/-UseTinyObjectHeaders)
> - 8347710: [Lilliput] Implement 4 byte headers (alternative code path to L1, under new experimental flag, e.g. +/-UseTinyObjectHeaders)
>
> JDK 28:
> - Make +/-UseTinyObjectHeaders non-experimental
>
> JDK 29:
> - Make +UseTinyObjectHeaders on-by-default
> - Deprecate -UseTinyObjectHeaders
>
> JDK 30:
> - Obsolete -UseTinyObjectHeaders