Support for concurrent scavenge on x86

[andrewcraik]

Issue or pull request number:
eclipse-openj9/openj9#3054

Overview:
The above issue is tracking a series of changes being made to OpenJ9 to support the pause-less garbage collector on the x86 platform. The pause-less garbage collector technology was originally implemented on the z architecture targeting the z14 hardware generation.

Applies to the following JDK versions:
8 and later

Applies to the following platforms:
64-bit Linux X / Windows

For new command line options:
-Xgc:concurrentScavenge

This is the same option as on z. It takes no options and has the affect as it does on z. At present we expect to support all currently supported x86 hardware running 64bit Linux or Windows. We will provide further updates as implementation and testing concludes if further restrictions / qualifications on this are necessary.

This option is supported only on the 64-bit JVM with the Generational Concurrent (gencon) garbage collection policy. When this mode is enabled, the JVM attempts to reduce GC pause-times for response-time sensitive, large heap applications.

[andrewcraik]

@0dvictor and @amicic FYI I have created the docs issue for the addition of concurrent scavenge support on x86 - comment/emblish as necessary.

[SueChaplain]

More info from Andrew:

Please note that for 0.11 the concurrent scavenger GC policy is only supported for x86 JVMs running with compressed references. If the maximum heap size (Xmx) exceeds the critical boundary (I believe around 63G) then we will switch to running without compressed references and concurrent scavenge will not be recognized/used. Support for nonCR builds will be added in the next few weeks post 0.11.

@pmhayward - we'll need to validate the around 63G. @amicic - can you confirm please?

[pshipton]

The compressed refs switch occurs at 57GB. i.e. https://www.eclipse.org/openj9/docs/xcompressedrefs/

[amicic]

That is true, but I'll verify that the same boundary will be for when we end accepting -Xgc:concurrentScavenge. Interestingly, the boundary is 48G right now, but we still have one more change to be promoted regarding heap geometry. Once it's in I'll verify it.

[amicic]

All the changes for heap geometry are in and we (@dmitripivkine to be precise) just verified, that the 'magic' boundary for Concurrent Scavenger will be 57G (inclusive), or more generically the same boundary for which we can create Compressed Refs Heap.