Discussion: How to get to single object header layout

[Thomas Stüfe]

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.

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/6698a1b3/attachment.htm>