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

[Andrew Dinn]

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)