JDK-8176211 : Setting -XX:G1ConcRefinementThreads=0 gives different behavior to using default value of G1ConcRefinementThreads=0
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2017-03-06
  • Updated: 2022-08-08
  • Resolved: 2022-08-08
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8133051 - Concurrent refinement threads may be activated and deactivated at random
Relates :  
JDK-8134303 - Introduce -XX:-G1UseConcRefinement
Description
Explicitly setting -XX:G1ConcRefinementThreads=0 disables all threads, while just keeping G1ConcRefinementThreads at its default value of 0 means to use the default number of threads.

This is confusing.

This behavior has been probably been introduced with JDK-8133051.
Comments
The 0 "default" in the xxx_globals.hpp is not really a default, it's just a placeholder required by the syntax of the macros being used. The description text even says "Will be set ergonomically by default." So not an issue.
08-08-2022
I think this is the wrong way think about the semantics. The right way is an explicit value means use that value. If no explicit value, then default using ergonomics. The initial default value is a meaningless implementation artifact; we don't have a direct way to say "does not have a value, and an access attempt is an error", nor do we have a way to leave an option uninitialized. Using a bogus sentinel value as the "uninitialized" value has the usual typing problems. For example, these thread count options have an unsigned type, which is incompatible with a -1 sentinel value (for example). Making the count variable have a signed type has other problems. What one needs in a case like this is a separate "has a value" flag, and an access protocol that checks it. Using bare global variables for options and direct references to access them doesn't let us do that sort of thing. So I think either there is nothing to fix here, or there is a possibly large new feature task for option handling.
06-03-2017
Other options like -XX:ConcGCThreads also show similar behavior for forever (including eg. CMS). So it might be harder than expected to change this.
06-03-2017