JDK-8134303 : Introduce -XX:-G1UseConcRefinement
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-08-24
  • Updated: 2022-11-14
  • Resolved: 2022-10-20
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 20
20 b21Fixed
Related Reports
Blocks :  
JDK-8140255 - Move the management of G1YoungRemSetSamplingThread from G1ConcurrentRefine
Relates :  
JDK-8230187 - Throughput post-write barrier for G1
Relates :  
JDK-8172792 - JEP 308: Improve Dynamic Number of Thread Sizing for G1
Relates :  
JDK-8176211 - Setting -XX:G1ConcRefinementThreads=0 gives different behavior to using default value of G1ConcRefinementThreads=0
Relates :  
JDK-8062128 - Dramatic difference between UseConcMarkSweepGC and UseG1GC
Description
To turn off concurrent refinement you have to specify 

-XX:-G1UseAdaptiveConcRefinement -XX:G1ConcRefinementYellowZone=9999999  -XX:G1ConcRefinementRedZone=9999999  -XX:G1ConcRefinementGreenZone=9999999

There should be an easier way to do this, we could introduce a new flag called -XX:-G1UseConcRefinement
Comments
Changeset: 028e8b3d Author: Kim Barrett <kbarrett@openjdk.org> Date: 2022-10-20 20:29:19 +0000 URL: https://git.openjdk.org/jdk/commit/028e8b3d5e7e1791a9ed0af244f74d21fb12ba81
20-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10256 Date: 2022-09-14 00:36:18 +0000
14-09-2022
As part of other work (JDK-8137022) I'm introducing G1UseConcRefinement as a diagnostic option, allowing it to be disabled. The old hack mentioned above no longer works with my changes, since several of those options are no longer meaningful. So I've taken this change.
08-08-2022
I forgot about the adaptive flag. So the current incantation would be -XX:-G1UseAdaptiveConcRefinement -XX:G1ConcRefinementGreenZone=9999999 -XX:G1ConcRefinementThreads=0. That doesn't seem so bad to achieve a rather strange configuration. Doesn't warrant yet another option, IMO.
25-01-2017
I did not remember G1ConcRefinementThreads :) Yes, I think this switch would then at most be an abbreviation for G1ConcRefinementThreads and the green threshold. I agree that we can close this then. Thanks for the clarification. Edit: Actually you also need to disable adaptive concurrent refinement too. Not sure at what amount of flags you need an abbreviation :)
25-01-2017
We already have G1ConcRefinementThreads. I think JDK-8133051 made -XX:G1ConcRefinementThreads=0 create no threads. That plus setting the zone flags appropriately (I think setting the green zone very large might be sufficient) to effectively disable refinement by mutators will move all the refinement into pauses. That's why I suggest "won't fix" earlier, unless the point is to invoke some entirely different mode. I think we already have enough knobs on the current mode.
25-01-2017
Instead of binary enable/disable, it may be more useful to allow specification a particular (maximum) number of threads for refinement. Having always ParallelGCThreads refinement threads in use is a waste of resources (and impacts startup).
25-01-2017
David says: Please keep in mind that concurrent refinement is also done by mutators, and this entry point should also be guarded by this flag.
28-10-2015
There used to be a UseConcRefinement variable (or something close), but it went away a few years back.
28-10-2015