On Tue, 21 Oct 2025 15:16:06 GMT, Erik Österlund <[email protected]> wrote:
>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any
>> GC.
>>
>> The current mechanism for the AOT cache to cache heap objects is by using
>> mmap to place bytes from a file directly in the GC managed heap. This
>> mechanism poses compatibility challenges that all GCs have to have bit by
>> bit identical object and reference formats, as the layout decisions are
>> offline. This has so far meant that AOT cache optimizations requiring heap
>> objects are not available when using ZGC. This work ensures that all GCs,
>> including ZGC, are able to use the more advanced AOT cache functionality
>> going forward.
>>
>> This JEP introduces a new mechanism for archiving a primordial heap, without
>> such compatibility problems. It embraces online layouts and allocates
>> objects one by one, linking them using the Access API, like normal objects.
>> This way, archived objects quack like any other object to the GC, and the GC
>> implementations are decoupled from the archiving mechanism.
>>
>> The key to doing this GC agnostic object loading is to represent object
>> references between objects as object indices (e.g. 1, 2, 3) instead of raw
>> pointers that we hope all GCs will recognise the same. These object indices
>> become the key way of identifying objects. One table maps object indices to
>> archived objects, and another table maps object indices to heap objects that
>> have been allocated at runtime. This allows online linking of the
>> materialized heap objects.
>>
>> The main interface to the cached heap is roots. Different components can
>> register object roots at dump time. Each root gets assigned a root index. At
>> runtime, requests can be made to get a reference to an object at a root
>> index. The new implementation uses lazy materialization and concurrency.
>> When a thread asks for a root object, it must ensure that the given root
>> object and its transitively reachable objects are reachable. A new
>> background thread called the AOTThread, tries to perform the bulk of the
>> work, so that the startup impact of processing the objects one by one is not
>> impacting the bootstrapping thread.
>>
>> Since the background thread performs the bulk of the work, the archived is
>> laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such
>> that the object indices and the DFS traversal orders are the same. This way,
>> the DFS traversal that the background thread is performing is the same order
>> as linearly materializing the objects one by one in the or...
>
> Erik Österlund has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change streaming/mapping states to be binary instead of tri states
Fix for minimal:
diff --git a/src/hotspot/share/cds/heapShared.hpp
b/src/hotspot/share/cds/heapShared.hpp
index 8fa00b8f47d..4cf3e53011e 100644
--- a/src/hotspot/share/cds/heapShared.hpp
+++ b/src/hotspot/share/cds/heapShared.hpp
@@ -576,9 +576,9 @@ class HeapShared: AllStatic {
static void setup_test_class(const char* test_class_name) PRODUCT_RETURN;
#endif // INCLUDE_CDS_JAVA_HEAP
+ public:
static void finish_materialize_objects() NOT_CDS_JAVA_HEAP_RETURN;
- public:
static void write_heap(ArchiveMappedHeapInfo* mapped_heap_info,
ArchiveStreamedHeapInfo* streamed_heap_info) NOT_CDS_JAVA_HEAP_RETURN;
static objArrayOop scratch_resolved_references(ConstantPool* src);
static void add_scratch_resolved_references(ConstantPool* src, objArrayOop
dest) NOT_CDS_JAVA_HEAP_RETURN;
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3432332019
