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

[Thomas Stuefe]

On Fri, 7 Jul 2023 23:16:00 GMT, Ioi Lam <iklam 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 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 a...

> > @iklam in your performance tests for "java -version" what is the "heap data relocation delta"? Is it non-zero? If so, can you also add the numbers for the runs with -Xmx128m which would correspond to the best case where no relocation is done just to add another data point.
> 
> 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.
> 

I must be missing something basic, but I don't understand Ashu's question nor the answer.

You now allocate space for each object individually, then memcopy it to the allotted space, right? How could there *not* be relocation involved, for either absolute or narrow oop? The chance that the object is allocated at exactly the same address or at the same offset to heap start as in the dump JVM  must be vanishingly low, right?

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

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