• Sub-task
    • Resolution: Fixed
    • P3
    • 18
    • 18
    • hotspot
    • b14



      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


      + 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.


      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


        Issue Links



              iklam Ioi Lam
              iklam Ioi Lam
              0 Vote for this issue
              3 Start watching this issue