JDK-8236988 : Modular Design for JVM Flags
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2020-01-13
  • Updated: 2020-09-11
  • Resolved: 2020-04-20
Related Reports
Relates :  
JDK-7123237 - Hotspot command line switches should have multiple type attributes
Relates :  
JDK-8237807 - Store command-line flags in a hashtable
Relates :  
JDK-8245226 - Clean-up FlagSetting and remove misuse.
Relates :  
JDK-7123237 - Hotspot command line switches should have multiple type attributes
Relates :  
JDK-8236606 - Generate source code for the JVMFlag::flags table
Relates :  
JDK-8243205 - Modularize JVM flags declaration
Description
DESIGN DOC: https://wiki.openjdk.java.net/display/HotSpot/HotSpot+Command-Line+Flags+Overhaul+-+Design+Doc

(The below description is a bit out-dated. Will fix soon. For now please refer to the link above for motivation and proposed design).
====
Currently all JVM flags are grouped under a giant macro ALL_FLAGS

http://hg.openjdk.java.net/jdk/jdk/file/2fbc66ef1a1d/src/hotspot/share/runtime/globals.hpp#l2539

This is very hard to maintain. Erik ��sterlund and Stefan Karlsson have suggested a new design where flags can be individually maintain by different modules. The basic idea is to declare a flag like this in a header file:

extern int SomeFlag;

and then define the flag in a C file:

int SomeFlag = initial_val;
ProductFlag  Flag_SomeFlag("SomeFlag, &SomeFlag, .....);

We can build up a list of all the ProductFlags in the VM (using C++ static initialization) for command-line processing, etc.

class ProductFlag {
    static ProductFlag* _head;
    ProductFlag* _next;
    void* _value_addr;
    char* _name;
public:
    ProductFlag(char* name, void* valid_addr, ...) {
        _name = name;
        _value_addr = value_addr;
        _next = _head;
        _head = this;
        ... 
    }
};

This list will replace the flagTable[] in

http://hg.openjdk.java.net/jdk/jdk/file/2fbc66ef1a1d/src/hotspot/share/runtime/flags/jvmFlag.cpp#l825
Comments
Closing this RFE as the proposed approach of using one global C++ class instance per flag is too drastic of a change (per John's comment above). JDK-8243205 can accomplish this with much smaller impact.
20-04-2020
In response to John's comment, I think we can keep the macro approach, but achieve the modularization of the flags by doing this in each module, like c1_globals.hpp: #define C1_FLAGS(develop, develop_pd, product, .........) \ develop(intx, C1FlagA, 123, "some flag A for C1) \ product(intx, C1FlagB, 456, "some flag B for C1) DECLARE_FLAGS(C1_FLAGS) The DECLARE_FLAGS macro will expand to this (in product build) extern intx C1FlagA; const intx C1FlagB = 456; Most of the HotSpot files that reference C1FlagA/C1FlagB can simply include c1_globals.hpp, without including the other unrelated xxx_globals.hpp file. DECLARE_FLAGS would be a generalization of what we have here: http://hg.openjdk.java.net/jdk/jdk/file/4a5a7dc9d05c/src/hotspot/share/runtime/globals.hpp#l2498 #define DECLARE_FLAGS(FLAG_DOER) \ FLAG_DOER(DECLARE_DEVELOPER_FLAG, \ DECLARE_PD_DEVELOPER_FLAG, \ DECLARE_PRODUCT_FLAG, \ DECLARE_PD_PRODUCT_FLAG, \ DECLARE_DIAGNOSTIC_FLAG, \ DECLARE_PD_DIAGNOSTIC_FLAG, \ DECLARE_EXPERIMENTAL_FLAG, \ DECLARE_NOTPRODUCT_FLAG, \ DECLARE_MANAGEABLE_FLAG, \ DECLARE_PRODUCT_RW_FLAG, \ DECLARE_LP64_PRODUCT_FLAG, \ IGNORE_RANGE, \ IGNORE_CONSTRAINT) For tracking purposes, I created a new RFE JDK-8243205 for the approach described in this comment.
20-04-2020
The implementation of the flags (jvmFlag.cpp, jvmFlagConstraintList.cpp, jvmFlagRangeList.cpp) should also be cleaned up. This can also be done while keeping the existing macro approach (with slight modifications). I'll file a separate REF.
20-04-2020
The proposed solution is likely to generate a bunch of new linker symbols, which (at some times in the past) have had their own scalability problems. The current solution, and tool-based solutions, are able to organize data and metadata in a mix row-wise and column-wise representations. Because metadata (such as name strings) tends to be more uniform than actual variable values, column-wise representations are good for metadata. You can have a single C object (top-level linked variable) per metadata column, instead of O(N) named structs. The present scheme features a large macro that is multi-use and can (in different uses) generate both metadata columns and row-wise named declarations (e.g., the actual variable declarations). Let's put on the table a modification of the present scheme which retains that feature, of mixed row-wise and column-wise expansions. I suggest a *multiple-include* file "xxx.globals.hpp" which carries the same data (in a similar form) as the existing multiple-use macro. The special suffix ".globals.hpp" means that the file is to be included only in an environment which is prepared to process the specialized data in the file. The file as a whole would contain only a mix of comments, CPP directives, and macro calls *without surrounding punctuation*. (Compare the body of the present macro, which has macro calls, whitespace, and continuation characters "\\". The file-based notation is therefore somewhat richer but still basically a sequence of expansion points.)
17-04-2020