RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v10]

[Erik Österlund]

On Sun, 26 Oct 2025 08:40:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Can you talk a little bit about the cost of doing all this? There's something superficially attractive about simply mapping the heap into memory at startup time. Will that continue to be an option with some GCs?

Sure. It depends a bit on the size of the archived objects. With a small archive, the entire thing is pretty cheap and there isn't much of a problem. The larger the archive, the more the background thread is able to take on the majority of the cost. Currently, running Spring PetClinic, there seems to be about ~2 MB of objects in the AOT cache, and the bootstrapping thread stalls for a total of 2 ms loading the objects, while the background thread materializes most of the objects in 6 ms while the JVM is starting.

Here are some sample measurements how long it takes to run create_vm in Spring PetClinic:

JVM start time mapping:
34 ms
34 ms
35 ms
34 ms
36 ms

JVM start time streaming:
36 ms
34 ms
38 ms
36 ms
36 ms

Once you start running the actual application, differences quicky fade away into noise as it takes several seconds to start Spring PetClinic.

The option to just map the memory is only available for G1 and only when not using windows. And it only does just the mapping when the compressed oops mode matches, otherwise all edges are processed. Nevertheless, when compressed oops is disabled, we will continue to use the previous mechanism heuristically. This might change in the future, but was a choice to mitigate risk now and give us some time to evaluate the options, as we likely start scaling up the number of archived objects going forward.

Hope this helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3450624012