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

[Ashutosh Mehra]

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 at 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%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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250201/b9456c04/attachment.htm>