eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 720 forks source link

Shared cache hints for GC heap size #3743

Closed pshipton closed 5 years ago

pshipton commented 5 years ago

Remembering the previous heap size settings (-Xmn, -Xmo) after startup can provide a significant startup benefit in subsequent runs, and can improve footprint as well. The GC data can be stored in the shared cache as a hint. https://unbscholar.lib.unb.ca/islandora/object/unbscholar%3A8100/datastream/PDF/view https://ieeexplore.ieee.org/document/8121911

Since a shared cache can be used to run more than one application, which may have different heap requirements, the hint should be associated with an application, or at least a main class.

As by design the GC is initialized before the shared cache, new GC APIs will be needed to adjust the GC heap parameters after initialization. Since the heap parameters can be adjusted before any objects are created, it can happen with very low cost.

Doc issue https://github.com/eclipse/openj9-docs/issues/324

pshipton commented 5 years ago

test high JVM count simultaneous startup scenario

This is just a matter of starting a number of JVMs at approximately the same time, such as starting up 20 JVMs running the SwingSet demo.

DanHeidinga commented 5 years ago

The option has been added for 0.15. Moving to 0.16 to consider enabling by default

amicic commented 5 years ago

I've done some basic testing to confirm everything is order, and there are no races with first GC.

pshipton commented 5 years ago

@amicic has the concern about always writing to the cache been addressed? i.e. the GC code will only attempt to write a hint if it has calculated a different value than has already been stored to the cache? If this is addressed, I suggest we enable the feature by default just after branching for the 0.15 release, to give time to identify any problems before the next release.

amicic commented 5 years ago

The hint is always updated. Values will almost always be different. I have not done anything to test if there is a problem with excessive updates.
We could still try to reduce it, blindly. Perhaps update it if 1) it differs by some margin (>10%) or 2) with low probability (10%) even if within the margin. The latter is to ensure it's updated in very gradual run-to-run load change.

pshipton commented 5 years ago

We shouldn't enable the feature by default until this has been resolved. Writing to the shared cache on every startup affects starting up multiple JVMs concurrently, as each JVM will serialize on the write to the cache.

amicic commented 5 years ago

A multiJVM test... I used a fairly simple workload (single threaded, very few classes and methods). Started 50 JVMs simultaneously, on a machine with 120 threads. GC thread and compilation thread count reduced to 2 and 1 respectively. Measured average time to complete the tests as reported by Linux time command, in seconds.

4 group of tests, with 4-6 sequential runs within each group. Before each group, SC was wiped.

SC alone appears to regress completion time (since the test is so simple, there is probably no benefit of SC, but there is some cost of maintaining SC?). However, use of hints does not seem to introduce additional regression.

no SC 7.7104 7.08792 7.25356 8.0851

SC, no hints 9.23496 8.95598 9.325 8.82136

SC, use hints 7.41268 10.0347 7.37226 8.4999 8.2855 8.60048

SC, use hints, skip insignificant updates 7.53726 8.9249 9.76732 8.5943 10.1544 7.5088

hangshao0 commented 5 years ago

SC alone appears to regress completion time (since the test is so simple, there is probably no benefit of SC, but there is some cost of maintaining SC?).

Might be the same issue as https://github.com/eclipse/openj9/issues/5918. Using -Xshareclasses:noTimestampChecks can workaround this issue.

amicic commented 5 years ago

@pshipton I understand the concern. There might be a real problem, but I'm reluctant to add additional logic before observing a problem and proving the logic helps. If you or somebody else try and succeed to create a problem with their own scenarios, I'm more than willing to investigate...

pshipton commented 5 years ago

@amicic based on the results in https://github.com/eclipse/openj9/issues/3743#issuecomment-503670540, I agree it seems fine as-is. ~What platform did you test on?~ nm, I see Linux.

pshipton commented 5 years ago

@amicic do you agree to enable -XX:+UseGCStartupHints by default next week after the branch for the 0.15 release?

DanHeidinga commented 5 years ago

@amicic We've branched for 0.15.0. Can enable -XX:+UseGCStartupHints by default?

amicic commented 5 years ago

PR that enables it by default has just been merged.

pshipton commented 5 years ago

Since https://github.com/eclipse/omr/pull/4079 is merged, I believe this can be closed.