JDK-7123237 : Hotspot command line switches should have multiple type attributes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs23,15
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-20
  • Updated: 2023-01-03
  • Resolved: 2023-01-03
Related Reports
Duplicate :  
JDK-8243208 - Clean up JVMFlag implementation
Relates :  
JDK-8236988 - Modular Design for JVM Flags
Relates :  
JDK-8236988 - Modular Design for JVM Flags
Relates :  
JDK-8243209 - Generate JVMFlag hashtable with constexpr
Description
Command line switch descriptors in Hotspot are defined by "struct Flag" in
globals.hpp.  Each switch has a "type" field that says whether the switch
is manageable, experimental, product, etc.  Currently, "type" is a character
string, and determining the switch type involves executing strcmp, which is
a slow operation.  What's more, a switch can be of only a single type.
E.g., one can have a "manageable" switch and an "experimental" switch,
but not a "manageable_experimental" switch.

Hotspot should support multiple types per switch.
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
03-01-2023
A lot has been changed since this RFE was filed over 10 years ago. Most of the issues raised by this RFE has been resolved since JDK-8243208. There is also enough infrastructure to support having a flag with, for example, both DIAGNOSTIC and MANAGEABLE attributes, although the current implementation forbids that. I propose that this RFE should be closed. If new changes are desired, a new RFE should be filed (with corresponding CSR, etc).
20-01-2022
From globals.hpp: // MANAGEABLE flags are writeable external product flags. // They are dynamically writeable through the JDK management interface // (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. // These flags are external exported interface (see CCC). The list of // manageable flags can be queried programmatically through the management // interface. // // A flag can be made as "manageable" only if // - the flag is defined in a CCC as an external exported interface. // - the VM implementation supports dynamic setting of the flag. // This implies that the VM must *always* query the flag variable // and not reuse state related to the flag state at any given time. // - you want the flag to be queried programmatically by the customers. So being Manageable is more than just being writeable.
07-04-2021
Could you describe the difference between a flag with the "writeable" property and one with the "manageable" property. Maybe take the following product flag, which is tagged with the MANAGEABLE "extra attribute" (or property, if you will), as an example: product(uintx, G1PeriodicGCInterval, 0, MANAGEABLE, \ And, assuming the necessary code for WRITEABLE is in place, create a new flag: product(uintx, G1PeriodicGCIntervalNew, 0, WRITEABLE, \ what would the actual difference be between those two flags? Maybe that would help me understand why you are arguing for having a "manageable" kind.
06-04-2021
I think my argument is that I think we should completely get rid of the notion of _kinds_. The reason why it doesn't make sense to combine them, is probably because we talk about the higher-level concept of _kinds_, that by their definitiond are very restrictive. But I think we should be talking about the _properties_ instead. If I want to be able to write and/or query a flag during runtime, I'm currently forced to mark the flag as a Manageable _kind_, and with that comes the strict requirement that the flag is a product (not debug, experimental, nor diagnostic) flag. But I don't necessarily want that. I might want to be able to use this feature/property for debug flags, or experimental flags. So, I want to decouple the "manageable" _property_ from the Manageable _kind_. With that scheme, product+manageable flags would still have the same "purpose, support level and properties" as the Manageable flags. We don't lose the previous strictness of our Manageable/product+manageable flags, but we gain the flexibility to add something that at least few of us wants.
06-04-2021
I think different kinds of product flags are important to have because of what they signify in terms of support and intended usage (eg. why you have to unlock some of them). That is why I suggest there should be a writeable property as distinct from a "manageable" property, so that we can keep the distinction. Really writeable is the only interesting property to apply across the board with any kind of flag (though it is somewhat historical accident that not all flags have been writeable from the start). I don't see any reason to support multiple kinds of non-product flags as it gains you nothing given all debug flags are equal in terms of support-level, and there is no need to lock any of them.
06-04-2021
I think this conflates different _kinds_ of flags with different _properties_ of flags. As defined today, Experimental, Diagnostic and Manageable are all kinds of flags each with their own purpose, support level and properties. It makes no sense to combine these "kinds" of flags together. What does make sense is to recognise a property, like writeable, which is currently implicit. A Manageable flag is a writeable, product flag. It makes sense to have writeable Diagnostic and writeable Experimental flags as well. Arguably experimental is also a property, rather than a kind of flag You can imagine that when a feature is fully product ready that it may be associated with regular product flags, diagnostic flags and some Manageable flags. You can then argue that whilst the feature is experimental all those flags should exist as just stated but also with the "experimental" bit flipped on. That is not an unreasonable way to look at things if starting from scratch, but IMO, it muddies the existing waters too much because we already associate non-functional attributes, like level-of-support, with the existing kinds of flags, and experimental flags and manageable flags have different support levels. Rather I would argue that whilst a feature is experimental all its flags are simply experimental, and by the time the feature is made non-experimental we then decide which of the flags should be regular, diagnostic or manageable.
05-04-2021
This RFE is still not addressed. Since, JDK-8243208, it's structurally possible to declare a flag like this: develop(bool, PrintClassHistogram, false, MANAGEABLE | EXPERIMENTAL, ...) However, we have runtime checks that disallow such declaration: https://github.com/openjdk/jdk/blob/66d9961cbd83dbfca20b0af3c20693438d4aff3f/src/hotspot/share/runtime/flags/jvmFlag.cpp#L684 void JVMFlag::check_all_flag_declarations() { for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) { int flags = static_cast<int>(current->_flags); // Backwards compatibility. This will be relaxed/removed in JDK-7123237. int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL; if ((flags & mask) != 0) { assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || (flags & mask) == JVMFlag::KIND_MANAGEABLE || (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, "%s can be declared with at most one of " "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); assert((flags & KIND_NOT_PRODUCT) == 0 && (flags & KIND_DEVELOP) == 0, "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL " "attribute; it must be declared as a product flag", current->_name); } } }
01-04-2021
A CSR is needed. This will be done after JDK-8243209.
22-08-2020
A few people in the GC team has wanted to be able to annotate all types of flags to be "manageable". I've created a prototype for this: https://cr.openjdk.java.net/~stefank/7123237/webrev.01/ The patch: * makes it possible to annotate product, diagnostic, experimental, and development flags to be manageable. ** getDiagnosticOptions() only return unlocked/available manageable flags (Didn't implement that, so it must already be in place) * removed product_rw * removed writeable() macro + infrastructure The code to make a flag manageable mimics the range and constraint macros: product(uintx, MinHeapFreeRatio, 40, \ "The minimum percentage of heap free after GC to avoid expansion."\ " For most GCs this applies to the old generation. In G1 and" \ " ParallelGC it applies to the whole heap.") \ range(0, 100) \ constraint(MinHeapFreeRatioConstraintFunc,AfterErgo) \ manageable() \ and maybe more interesting: develop(bool, Verbose, false, \ "Print additional debugging information from other modes") \ manageable() \ -XX:+PrintFlagsFinal doesn't look that pretty atm, and needs to be thought about: $ ../build/fastdebug/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep manageable intx CMSAbortablePrecleanWaitMillis = 100 {manageable product} {default} intx CMSTriggerInterval = -1 {manageable product} {default} intx CMSWaitDuration = 2000 {manageable product} {default} bool ForceNUMA = false {manageable experimental} {default} uintx G1PeriodicGCInterval = 0 {manageable product} {default} double G1PeriodicGCSystemLoadThreshold = 0.000000 {manageable product} {default} uint HandshakeTimeout = 0 {manageable diagnostic} {default} bool HeapDumpAfterFullGC = false {manageable product} {default} bool HeapDumpBeforeFullGC = false {manageable product} {default} bool HeapDumpOnOutOfMemoryError = false {manageable product} {default} ccstr HeapDumpPath = {manageable product} {default} uintx MaxHeapFreeRatio = 70 {manageable product} {default} uintx MinHeapFreeRatio = 40 {manageable product} {default} bool PrintClassHistogram = false {manageable product} {default} bool PrintConcurrentLocks = false {manageable product} {default} bool UseNUMA = false {manageable product} {default} bool Verbose = false {manageable develop} {default}
20-05-2019
We don't think we need multiple attributes for command line parameters at this time. Closing as WNF
10-03-2014
SUGGESTED FIX A possible implementation is to make Flag.type be a scalar bitset rather than a string, thus making it possible to encode more than one value.
20-12-2011