Discussion: How to get to single object header layout

[coleen.phillimore at oracle.com]

On 2/27/25 3:32 PM, Thomas Stüfe wrote:
> Hi Coleen,
>
> I did benchmarks end of last year, and found the numbers for Lilliput1 
> to be encouraging. This was on the very-close-to-release version of 
> Lilliput. I will brush up the results or repeat the measurements when 
> I find time, but in short, I found in SpecJBB G1 pause time 
> reduction of ~20% and CPU cache misses down by 15-20%. Live set size 
> reduction of ~17%. Benchmark scores were also better.

Thomas, this is good.  Please post these results in the JDK issue, and 
what you measured and what sort of hardware configurations when you have 
a chance.

Thanks,
Coleen

>
> I remember that Romans results were a bit smaller, but I usually test 
> on older hardware that may benefit more from more efficient CPU/memory 
> use.
>
> Cheers, Thomas
>
>
> On Thu, Feb 27, 2025 at 9:02 PM <coleen.phillimore at oracle.com> wrote:
>
>
>     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250227/710a4302/attachment-0001.htm>