Sketched breakdown of task for implementing code save/restore in Leyden repo and mainline
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. 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, ???) Migration steps: ---------------- 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 More speculative improvements: ------------------------------ (do we prototype these in premain before migrating?) 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)
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%2... 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
There is also the "portability" aspect of the compiled code. I know it has come up for discussion in the past, but I don't remember if we decided to do anything about it. If we are planning to move things to the mainline, then probably this is a good time to revisit it. - Ashutosh Mehra On Fri, Jan 31, 2025 at 1:55 PM Vladimir Kozlov <vladimir.kozlov@oracle.com> wrote:
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%2...
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
participants (3)
-
Andrew Dinn
-
Ashutosh Mehra
-
Vladimir Kozlov