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

[Dan Heidinga]

On Mon, 10 Jul 2023 05:35:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The cost is about 1.3 ms per MB of archived heap objects. This may be acceptable as it's a small fraction of JVM bootstrap. We have about 1MB of archived objects now, and we don't expect this size to drastically increase in the near future.

Looking ahead to Project Leyden, I wouldn't be surprised if the current 1MB of archived heap became much larger.  Demo apps on Graal Native Image are often ~4MB of image heap, and while it's not an apples-to-apples comparison, it suggests that somewhere between 5MB & 10MB isn't unreasonable for Leyden.

Using 10MB as a baseline for easy math,  1.3ms/MB * 10MB = 13 ms for the new code?  And (1.3ms-0.8ms) = 0.5ms/MB * 10MB = 5ms for the old code?  Assuming I've interpreted the numbers correctly and importably that they scale linearly, it seems worth preserving the mmap approach for collectors that can support it.

Does that seem reasonable?  And justify preserving the mmap approach?

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

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