-
Sub-task
-
Resolution: Fixed
-
P3
-
18
-
b14
Overview:
This is the first step for supporting archived heap objects for non-G1 collectors (JDK-8234679). We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
+ Only G1 can write archive heap objects into the CDS archive.
+ Archived objects are "mapped" by G1, but the mapping operation is quite complex.
+ All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in
virtual bool can_load_archived_objects();
virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
Implementation:
+ Allocate (from the Java Heap) a buffer that's large enough to contain all the archived heap objects.
+ Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
+ Copy every region in to the buffer consecutively, without any gaps.
+ Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
+ The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
Benchmarking:
We can see significant start-up improvement because the module graph can be loaded from CDS.
$ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
Before: 43.1ms
After: 30.2ms
This is the first step for supporting archived heap objects for non-G1 collectors (
+ Only G1 can write archive heap objects into the CDS archive.
+ Archived objects are "mapped" by G1, but the mapping operation is quite complex.
+ All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in
virtual bool can_load_archived_objects();
virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
Implementation:
+ Allocate (from the Java Heap) a buffer that's large enough to contain all the archived heap objects.
+ Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
+ Copy every region in to the buffer consecutively, without any gaps.
+ Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
+ The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
Benchmarking:
We can see significant start-up improvement because the module graph can be loaded from CDS.
$ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
Before: 43.1ms
After: 30.2ms
- is blocked by
-
JDK-8272348 Update CDS tests in anticipation of JDK-8270489
-
- Resolved
-
- relates to
-
JDK-8273256 runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
-
- Resolved
-
-
JDK-8274033 Some tier-4 CDS EpsilonGC tests throw OOM
-
- Resolved
-
-
JDK-8274166 Some CDS tests ignore -Dtest.cds.runtime.options
-
- Resolved
-
(1 links to)