Sketched breakdown of task for implementing code save/restore in Leyden repo and mainline

[Vladimir Kozlov]

Thank you, Andrew, for layout our future steps.

Here is AOT wishlist RFE John created few months ago:
https://bugs.openjdk.org/browse/JDK-8343023

We finished some items listed in this RFE and are still working on 
others. May be we need to update it with new items we discussed.

I think we should file new RFEs (if we don't have one) for tasks you 
listed. Current AOT RFEs list [1]

My comments are inside.

[1] 
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


On 1/31/25 9:08 AM, Andrew Dinn wrote:
> Hi all,
> 
> Following up on our discussion in yesterday's meeting I have sketched 
> below a list of the various tasks we need to perform to implement code 
> save/restore, both immediately with the hope of getting them into jdk25 
> and in the longer term. The list includes some things it would be 
> preferable to prototype in the Leyden premain branch before transferring 
> to mainline, other migration tasks that serve to transfer existing 
> protptype code from premain to mainline and more speculative tasks that 
> are unlikely to be achievable for jdk25.
> 
> Please review and feel free to offer additions and corrections -- I am 
> not at all sure I have it all down and/or correct.
> 
> n.b. one general note that applies to all migration or direct, mainline 
> implementation tasks is that we need to consider how we handle CPUs 
> other than aarch64/x86_64 and OSes other than Linux. Even if we leave 
> AOT code cache functionality 'unimplemented' for other ports we will 
> still need to ensure that the code we migrate will successfully allow 
> for missing ('not yet available') implementations.  When performing the 
> migration tasks we may well want/need to pull in devs from those other 
> ports to, at least, help achieve that minimum goal or, perhaps, 
> implement some subset of the relevant functionality.

Agree. And we do that already during mainline PR reviews.

> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
> 
> Leyden repo preliminaries:
> --------------------------
> 
> Modify SCCache implementation to save/restore code in the AOT cache file 
> with metadata, heap data etc.


> 
> Complete save/restore of i2c2i adapters and associated index
> 
> Complete direct install of mapped AOT adapter code into CodeCache
> 
> Complete direct install of nmethod code into CodeCache
> 
> Rework save/restore of runtime, c1, opto and stubgen blobs & stubs after 
> merge of mainline stub cleanup
> 
> Implement save/restore of other demand-generated linkage stubs (i/vtable 
> adapters, method handle adapters, ICCache, ???)

We have mainline PR in review to move Relocation section, oops and 
metadata sections which requires patching out of CodeCache:
https://github.com/openjdk/jdk/pull/21276

> 
> 
> Migration steps:
> ----------------

I think we should start with replacing separate file for AOT cached code 
with space provided by CDS to have only one file for all cached information.

> 
> Migrate SCCache support to save/restore i2c2i adapters and associated 
> lookup tables and relink methods with correct adapters
> 
> Incrementally extend SCCache to support save/restore of other demand- 
> geerated adapters and associated lookup tables
> 
> Implement save/restore of runtime, c1, opto and stubgen blobs & stubs
> 
> Implement save/restore of special case nmethods and associated index 
> info (i.e. compiled MethodHandle adapter nmethods associated with Java 
> MethodTypes and associated Java lookup table -- any others)
> 
> Implement save/restore of general nmethods
> 

> Implement prelinking of nmethod -> nmethod call sites
> 
> Implement prelinking of nmethod -> stub call sites

https://bugs.openjdk.org/browse/JDK-8343790

> 
> 
> More speculative improvements:
> ------------------------------
> 
> (do we prototype these in premain before migrating?)

Yes, we should prototype it in `premain` branch.
> 
> Adjust code generation to store runtime addresses in nmethod constant 
> section and use pc-relative loads (minimizing relocs) -- requires new 
> relocs for gloal addresses and/or extending CDS link patching to include 
> extra 'code address' pass.
> 
> Investigate further use of 'code cache' global constant section instead 
> of per nmethod constant sections.
> 
> Investigate use of compressed nmethod 'debug info' to minimize size of 
> AOT cache (n.b. best to use it compressed in mainline with or without 
> AOT so save/restore gets it for free)


Thanks,
Vladimir K