Bug ID: JDK-8241486 G1/Z give warning when using LoopStripMiningIter and turn off LoopStripMiningIter (0)

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 16
16 b14Fixed

I tested setting the LoopStripMiningIter which complained that UseCountedLoopSafepoints is off:

Java HotSpot(TM) 64-Bit Server VM warning: Disabling counted safepoints implies no loop strip mining: setting LoopStripMiningIter to 0

In g1Arguments.cpp  G1Arguments::initialize()
We do:
#ifdef COMPILER2
  // Enable loop strip mining to offer better pause time guarantees
  if (FLAG_IS_DEFAULT(UseCountedLoopSafepoints)) {

We should not give a warning and turn LoopStripMiningIter off.

[rehn@rehn-ws dev-jdk]$ java -XX:+PrintFlagsFinal -version | grep "Strip\|UseCountedLoopSafepoints"
    uintx LoopStripMiningIter                      = 1000                                   {C2 product} {default}
    uintx LoopStripMiningIterShortLoop             = 100                                    {C2 product} {default}
     bool UseCountedLoopSafepoints                 = true                                   {C2 product} {default}

[rehn@rehn-ws dev-jdk]$ java -XX:LoopStripMiningIter=100 -XX:+PrintFlagsFinal -version | grep "Strip\|UseCountedLoopSafepoints"
OpenJDK 64-Bit Server VM warning: Disabling counted safepoints implies no loop strip mining: setting LoopStripMiningIter to 0
    uintx LoopStripMiningIter                      = 0                                      {C2 product} {command line}
    uintx LoopStripMiningIterShortLoop             = 0                                      {C2 product} {default}
     bool UseCountedLoopSafepoints                 = true                                   {C2 product} {default}

URL: https://hg.openjdk.java.net/jdk/jdk/rev/f37cc2bd2ebf User: roland Date: 2020-08-27 11:49:54 +0000
27-08-2020
This is not a regression but default behavior since Loop Strip Mining was introduced in JDK 10 (JDK-8186027). I've added the corresponding affects versions. As Kim explained, the problem is that we check the flag constraint before ergo enabled UseCountedLoopSafepoints. I think it should be checked after ergo but I'll leave this to [~roland] to decide. Updated ILW = Unexpected warning and flag setting, with -XX:LoopStripMiningIter command line option, set -XX:+UseCountedLoopSafepoints = MLM = P4 Targeted for JDK 16.
26-06-2020
Roland, could you please have a look?
03-06-2020
I think the problem here could be argued to be user-error. The compiler configuration handling expects UseCountedLoopSafepoints and LoopStripMiningIter to be either both or neither set on the command line. Alternatively, it could be argued that the check that "Use" is explicitly set if "Iter" is non-zero is too early, and ought to be done as an AfterErgo constraint. Some of the GCs attempt to "default" UseCountedLoopSafepoints to on and LoopStripMiningIter to a value. That happens during apply_ergo(), which is after CompilerConfig::check_args_consistency is called and complains. If that constraint were an AfterErgo constraint, things would work as the reporter requested. It seems like there is a lot of constraint checking happening in ComplerConfig::check_args_consistency that perhaps should be using the JVMFlag constraint checking mechanism. Moving this over to the compiler subcomponent to decide which of those interpretations is correct and deal with accordingly.
03-06-2020
Epsilon and Shenandoah appear to have the same issue (not tested, but they have the same code snippet for setting UseCountedLoopSafepoints and LoopStripMiningIter in their XArguments::initialize()).
03-06-2020