P4
This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
The main implementation trick is to exploit concurrency between Java threads during bootstrapping and a new background thread that reads and allocates objects from the object archive.
In order to get decent concurrency, it's important that the threads can mostly work on disjoint data. This is ensured by ordering the objects in the archive in DFS order. This way, the system keeps track of three distinct regions in the object archive.
Region 1: Objects transitively materialized by the concurrent thread.
Region 2: Objects currently being transitively materialized by the concurrent thread.
Region 3: Objects not yet visited and won't be concurrently materialized by the concurrent thread.
These regions slide such that initially no objects belong to region 1 and eventually they all do.
Roots accessed by the program from region 1 can be looked up from a table. Roots accessed by the program from region 2 can wait for concurrent materialization to finish and then look up from a table.
Roots accessed by the program from region 3 can eagerly materialize the its transitive closure using a DFS traversal; each visited object goes through the same procedure.
The main idea is to use normal allocations and accesses, which gives the GC complete control over layout and accesses, hence detangling loading of archived objects from the GC internals. This allows ZGC to also load archived objects. The archive format itself is completely GC agnostic. References are logical numbers (DFS order number) as opposed to anything GC specific.
For now, the idea is to add this new mechanism but keep the old one so we can later evaluate if it's worth keeping or not. As for the JDK shipped archives, the one without compressed oops will use this new GC agnostic archive format, allowing ZGC to also use it.
The main implementation trick is to exploit concurrency between Java threads during bootstrapping and a new background thread that reads and allocates objects from the object archive.
In order to get decent concurrency, it's important that the threads can mostly work on disjoint data. This is ensured by ordering the objects in the archive in DFS order. This way, the system keeps track of three distinct regions in the object archive.
Region 1: Objects transitively materialized by the concurrent thread.
Region 2: Objects currently being transitively materialized by the concurrent thread.
Region 3: Objects not yet visited and won't be concurrently materialized by the concurrent thread.
These regions slide such that initially no objects belong to region 1 and eventually they all do.
Roots accessed by the program from region 1 can be looked up from a table. Roots accessed by the program from region 2 can wait for concurrent materialization to finish and then look up from a table.
Roots accessed by the program from region 3 can eagerly materialize the its transitive closure using a DFS traversal; each visited object goes through the same procedure.
The main idea is to use normal allocations and accesses, which gives the GC complete control over layout and accesses, hence detangling loading of archived objects from the GC internals. This allows ZGC to also load archived objects. The archive format itself is completely GC agnostic. References are logical numbers (DFS order number) as opposed to anything GC specific.
For now, the idea is to add this new mechanism but keep the old one so we can later evaluate if it's worth keeping or not. As for the JDK shipped archives, the one without compressed oops will use this new GC agnostic archive format, allowing ZGC to also use it.