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

[Erik Österlund]

On Mon, 31 Jul 2023 20:29:46 GMT, Dan Heidinga <heidinga 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?

I think Leyden has bigger fish to fry. If we start seeing this being costly, then there are still more cards we can play to optimize the GC agnostic approach, such as e.g. exploiting the mostly contiguous nature of our allocations. But I'd like to wait and see if it's worth it or not, compred to potentially bigger fish we can spend time on instead. I'm happy with current numbers, and see a path forward should we need them to improve going forward.

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

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