<div dir="ltr"><div>There is also the "portability" aspect of the compiled code.</div><div>I know it has come up for discussion in the past, but I don't remember if we decided to do anything about it.</div><div>If we are planning to move things to the mainline, then probably this is a good time to revisit it.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Ashutosh Mehra</div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2025 at 1:55 PM Vladimir Kozlov <<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you, Andrew, for layout our future steps.<br>
<br>
Here is AOT wishlist RFE John created few months ago:<br>
<a href="https://bugs.openjdk.org/browse/JDK-8343023" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8343023</a><br>
<br>
We finished some items listed in this RFE and are still working on <br>
others. May be we need to update it with new items we discussed.<br>
<br>
I think we should file new RFEs (if we don't have one) for tasks you <br>
listed. Current AOT RFEs list [1]<br>
<br>
My comments are inside.<br>
<br>
[1] <br>
<a href="https://bugs.openjdk.org/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20Enhancement%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20AND%20labels%20%3D%20leyden" rel="noreferrer" target="_blank">https://bugs.openjdk.org/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20Enhancement%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20AND%20labels%20%3D%20leyden</a><br>
<br>
<br>
On 1/31/25 9:08 AM, Andrew Dinn wrote:<br>
> Hi all,<br>
> <br>
> Following up on our discussion in yesterday's meeting I have sketched <br>
> below a list of the various tasks we need to perform to implement code <br>
> save/restore, both immediately with the hope of getting them into jdk25 <br>
> and in the longer term. The list includes some things it would be <br>
> preferable to prototype in the Leyden premain branch before transferring <br>
> to mainline, other migration tasks that serve to transfer existing <br>
> protptype code from premain to mainline and more speculative tasks that <br>
> are unlikely to be achievable for jdk25.<br>
> <br>
> Please review and feel free to offer additions and corrections -- I am <br>
> not at all sure I have it all down and/or correct.<br>
> <br>
> n.b. one general note that applies to all migration or direct, mainline <br>
> implementation tasks is that we need to consider how we handle CPUs <br>
> other than aarch64/x86_64 and OSes other than Linux. Even if we leave <br>
> AOT code cache functionality 'unimplemented' for other ports we will <br>
> still need to ensure that the code we migrate will successfully allow <br>
> for missing ('not yet available') implementations.  When performing the <br>
> migration tasks we may well want/need to pull in devs from those other <br>
> ports to, at least, help achieve that minimum goal or, perhaps, <br>
> implement some subset of the relevant functionality.<br>
<br>
Agree. And we do that already during mainline PR reviews.<br>
<br>
> <br>
> regards,<br>
> <br>
> <br>
> Andrew Dinn<br>
> -----------<br>
> <br>
> <br>
> Leyden repo preliminaries:<br>
> --------------------------<br>
> <br>
> Modify SCCache implementation to save/restore code in the AOT cache file <br>
> with metadata, heap data etc.<br>
<br>
<br>
> <br>
> Complete save/restore of i2c2i adapters and associated index<br>
> <br>
> Complete direct install of mapped AOT adapter code into CodeCache<br>
> <br>
> Complete direct install of nmethod code into CodeCache<br>
> <br>
> Rework save/restore of runtime, c1, opto and stubgen blobs & stubs after <br>
> merge of mainline stub cleanup<br>
> <br>
> Implement save/restore of other demand-generated linkage stubs (i/vtable <br>
> adapters, method handle adapters, ICCache, ???)<br>
<br>
We have mainline PR in review to move Relocation section, oops and <br>
metadata sections which requires patching out of CodeCache:<br>
<a href="https://github.com/openjdk/jdk/pull/21276" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/21276</a><br>
<br>
> <br>
> <br>
> Migration steps:<br>
> ----------------<br>
<br>
I think we should start with replacing separate file for AOT cached code <br>
with space provided by CDS to have only one file for all cached information.<br>
<br>
> <br>
> Migrate SCCache support to save/restore i2c2i adapters and associated <br>
> lookup tables and relink methods with correct adapters<br>
> <br>
> Incrementally extend SCCache to support save/restore of other demand- <br>
> geerated adapters and associated lookup tables<br>
> <br>
> Implement save/restore of runtime, c1, opto and stubgen blobs & stubs<br>
> <br>
> Implement save/restore of special case nmethods and associated index <br>
> info (i.e. compiled MethodHandle adapter nmethods associated with Java <br>
> MethodTypes and associated Java lookup table -- any others)<br>
> <br>
> Implement save/restore of general nmethods<br>
> <br>
<br>
> Implement prelinking of nmethod -> nmethod call sites<br>
> <br>
> Implement prelinking of nmethod -> stub call sites<br>
<br>
<a href="https://bugs.openjdk.org/browse/JDK-8343790" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8343790</a><br>
<br>
> <br>
> <br>
> More speculative improvements:<br>
> ------------------------------<br>
> <br>
> (do we prototype these in premain before migrating?)<br>
<br>
Yes, we should prototype it in `premain` branch.<br>
> <br>
> Adjust code generation to store runtime addresses in nmethod constant <br>
> section and use pc-relative loads (minimizing relocs) -- requires new <br>
> relocs for gloal addresses and/or extending CDS link patching to include <br>
> extra 'code address' pass.<br>
> <br>
> Investigate further use of 'code cache' global constant section instead <br>
> of per nmethod constant sections.<br>
> <br>
> Investigate use of compressed nmethod 'debug info' to minimize size of <br>
> AOT cache (n.b. best to use it compressed in mainline with or without <br>
> AOT so save/restore gets it for free)<br>
<br>
<br>
Thanks,<br>
Vladimir K<br>
<br>
<br>
</blockquote></div>