<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2/27/25 3:32 PM, Thomas Stüfe wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA-vtUyidwKYtJYaMiDz9N-7oEdTSkMVe8BPx=SyHK7TrkvR1g@mail.gmail.com">
<div dir="ltr">Hi Coleen,
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Thanks,<br>
Coleen<br>
<br>
<blockquote type="cite" cite="mid:CAA-vtUyidwKYtJYaMiDz9N-7oEdTSkMVe8BPx=SyHK7TrkvR1g@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers, Thomas</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2025 at
9:02 PM <<a href="mailto:coleen.phillimore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">coleen.phillimore@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Roman,<br>
<br>
Thank you for sending out the plan for getting to a single
object header <br>
layout. See below:<br>
<br>
On 2/26/25 1:52 PM, Kennke, Roman wrote:<br>
> (2nd attempt at sending this. If you receive the other
attempt, please ignore it.)<br>
><br>
> 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.<br>
><br>
> 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.)<br>
><br>
> 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.<br>
><br>
> Please let me know what you think, how we can make this
work, and especially whatever concerns you may have.<br>
><br>
> JDK 25:<br>
> - 8350272: Deprecate UseCompressedClassPointers for
removal<br>
> - 8350457: Support Compact Object Headers as product
option<br>
<br>
I filed 8350457 to collect information that we need to decide
to move <br>
UseCompactObjectHeaders out of Experimental mode. See the bug
for more <br>
details: <a href="https://bugs.openjdk.org/browse/JDK-8350457" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8350457</a><br>
<br>
One of the first and most important things we need is to show
that there <br>
is a performance improvement either in throughput or density
for this <br>
change. I assigned this to you, but I'm also currently in the
process <br>
of running our internal benchmarks to determine the impact of
this <br>
change and I'll post analysis there when I have more details.
Also we <br>
need some fresh performance results that you are seeing. If
the option <br>
is a product option, we need to tell people why they want to
use this <br>
option. There may be some performance regressions for some
applications <br>
with UCCP so we need to show to overall improvements in other
types of <br>
applications, and or mitigate the regressions.<br>
<br>
The remaining tasks for JDK 26 and beyond depend on what we
find as a <br>
result of this step, including L2, whose performance numbers
would be <br>
interesting to see as well.<br>
<br>
Thank you,<br>
Coleen<br>
<br>
><br>
> JDK 26:<br>
> - 8346011: [Lilliput] Compact Full-GC Forwarding
(required for UCCP removal, pre-req for L2)<br>
> - Obsolete +/-UseCompressedClassPointers<br>
> - Make +UseCompactObjectHeaders on-by-default<br>
> - Deprecate -UseCompactObjectHeaders<br>
><br>
> JDK 27:<br>
> - Obsolete -UseCompactObjectHeaders<br>
> - 8320761: [Lilliput] Implement compact identity hashcode
(alternative code path to L1, under new experimental flag,
e.g. +/-UseTinyObjectHeaders)<br>
> - 8347710: [Lilliput] Implement 4 byte headers
(alternative code path to L1, under new experimental flag,
e.g. +/-UseTinyObjectHeaders)<br>
><br>
> JDK 28:<br>
> - Make +/-UseTinyObjectHeaders non-experimental<br>
><br>
> JDK 29:<br>
> - Make +UseTinyObjectHeaders on-by-default<br>
> - Deprecate -UseTinyObjectHeaders<br>
><br>
> JDK 30:<br>
> - Obsolete -UseTinyObjectHeaders<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>