<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="DE" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">The plan sounds great to me. I especially like the plan for JDK 25. We will see if we need adjustments in the later releases.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I appreciate being able to use
</span><span lang="EN-US" style="font-size:11.0pt">Compact Object Headers in production with JDK 25 LTS. We can backport fixes to make it stable and reliable. The more people use it the better. In terms of testing and footprint savings.</span><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Martin<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">Von:
</span></b><span style="color:black">hotspot-dev <hotspot-dev-retn@openjdk.org> im Auftrag von Kennke, Roman <rkennke@amazon.de><br>
<b>Datum: </b>Mittwoch, 26. Februar 2025 um 19:53<br>
<b>An: </b>hotspot-dev@openjdk.org <hotspot-dev@openjdk.org><br>
<b>Betreff: </b>Discussion: How to get to single object header layout<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">(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>
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<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>