RFR: 8310160: Make GC APIs for handling archive heap objects agnostic of GC policy [v2]

[Ioi Lam]

On Wed, 5 Jul 2023 21:34:12 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > I first ran java -Xshare:dump so all the subsequent java --version runs use the same heap size as dump time. As a result, my "before" runs had a heap relocation delta of zero, which should correspond to the best start-up time.
> 
> Okay, thanks for clarifying. I thought `java --version` runs were using the default archive.

I haven't done any optimizations yet, but I fixed a few problems in the slow-path code. 

https://github.com/openjdk/jdk/compare/master...iklam:jdk:8310823-materialize-cds-heap-with-regular-alloc?expand=1


# Before: no relocation
$ perf stat -r 40 java --version > /dev/null
          0.015872 +- 0.000238 seconds time elapsed  ( +-  1.50% )

# Before: force relocation (quick)
$ perf stat -r 40 java -Xmx4g --version > /dev/null
          0.016691 +- 0.000385 seconds time elapsed  ( +-  2.31% )

# Before: force relocation ("quick relocation not possible")
$ perf stat -r 40 java -Xmx2g --version > /dev/null
          0.017385 +- 0.000230 seconds time elapsed  ( +-  1.32% )

# After
$ perf stat -r 40 java -XX:+NewArchiveHeapLoading --version > /dev/null
          0.018780 +- 0.000225 seconds time elapsed  ( +-  1.20% )


So the slow path is just about 3ms slower than the fastest "before" case.

Looking at the detailed timing break down (`os::thread_cpu_time()` = ns):


$ java -XX:+NewArchiveHeapLoading -Xlog:cds+gc --version
[0.006s][info][cds,gc] Num objs                    :                24184
[0.006s][info][cds,gc] Num bytes                   :              1074640
[0.006s][info][cds,gc] Per obj bytes               :                   44
[0.006s][info][cds,gc] Num references (incl nulls) :                87109
[0.006s][info][cds,gc] Num references relocated    :                43225
[0.006s][info][cds,gc] Allocation Time             :              1605084 <<<< A
[0.006s][info][cds,gc] Relocation Time             :              1246894
[0.006s][info][cds,gc] Table(s) dispose Time       :                 1306

$ java -XX:+NewArchiveHeapLoading -XX:NewArchiveHeapNumAllocs=2 -Xlog:cds+gc --version
[0.006s][info][cds,gc] Allocation Time             :              2203781 <<<< B

$ java -XX:+NewArchiveHeapLoading -XX:NewArchiveHeapNumAllocs=-1 -Xlog:cds+gc --version
[0.003s][info][cds,gc] Allocation Time             :               282125 <<<< C

$ java -XX:+NewArchiveHeapLoading -XX:NewArchiveHeapNumAllocs=0 -Xlog:cds+gc --version
[0.004s][info][cds,gc] Allocation Time             :               854249 <<<< D


The cost of allocating all the object is about 0.6 ms (B - A). Determining the size of the objects cost about 0.3ms (C). The cost of storing the relocation into the hastables is about 0.6 ms (D - C).

I hope to implement a fast path for relocation that avoids using the hash tables at all. If we can get the total alloc + reloc time to be about 1.5ms, then it would be just as fast as before when relocation is enabled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1626352390