RFC 8236988 - Modular Design for JVM Flags

[Liu, Xin]

Hi, Ioi, 

I'm recently refactoring intrinsics options for compiler[1]. I introduced a new option type called "intrinsics".  The biggest trouble was that I had to modify multiple places.  I found your patch beautifully replaces jvmConstraintList.* &jvmFlagRangeList.* with some macros in jvmFlag.inline.hpp. great!

I have some questions or suggests.

1. generate a document of options
There're hundreds of JVM options.  It's hard to learn them by heart. I feel developers uses globals.hpp and sub header files as a de factor manual. 
if you break up the monolithic header, which is good,  I think developers deserve a manual.  
Off the top of my head, I think you can provide a mini tool, which consume a header aggerates all sub-header files and automatically generates a manual.

2. change FLAG_RANGE and FLAG_CONTRAINT to optional parameters of PRODUCT_FLAG.
If you use variadic macro, it's possible to select RANGE or CONTRAINT or NIL from __VA_ARGS__.
I used to propose it before. https://cr.openjdk.java.net/~xliu/8230669/00/webrev/src/hotspot/share/utilities/macro_overloading.hpp.html

I think it's a good idea because it make the declaration section pure. 
If we replace those macros eg. PRODUCT_FLAG with C++ classes of same names, it's very easy to write a standalone tool to generate a manual of JVM options from header files, right? 

2. There's a TCL script.  Isn't C Processor powerful enough for it?  I don't know TCL, I think an external script will bring dependency and learning  burden.

3. let's say we choose a script generator. It looks like those globals_xxx.cpp files are auto-gen files. 
Will you consider to untrack those generated files in the repo? 

4. Probably, it's not a bad idea to still use product/develop instead of PRODUCT_FLAG, DEVELOP_FLAG. 
Those options will be read everyday by developers, I feel lower-case names are more friendly. 

[1]: https://cr.openjdk.java.net/~xliu/8151779/00/webrev/

Thanks,
--lx

On 4/9/20, 5:08 PM, "hotspot-dev on behalf of Ioi Lam" <hotspot-dev-bounces at openjdk.java.net on behalf of ioi.lam at oracle.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
    
    
    
    The code for specifying HotSpot command-line flags used to be simple. At
    the very beginning it was something like
    
         #define ALL_FLAGS(develop, develop) \
            product(int, SomeFlag, def_value, "some doc") \
            develop(int, MoreFlag, def_value, "more doc") \
    
    but like all good ideas, it has gradually degraded into a mess [1][2].
    It's now very difficult to add any new functionality (e.g., add
    "manageable" annotations to the flags [3]).
    
    I think it's time for a complete rewrite :-)
    
    My proposal is here. Please comment if it's a good or bad idea.
    
    https://wiki.openjdk.java.net/display/HotSpot/HotSpot+Command-Line+Flags+Overhaul+-+Design+Doc
    
    
    
    tldr; ---
    
    
    OLD:
    
       product(intx, AliasLevel, 3,                                          \
               "0 for no aliasing, 1 for oop/field/static/array split,
    "         \
               "2 for class split, 3 for unique
    instances")                      \
               range(0, 3)
    /*optional*/                                         \
               constraint(AliasLevelConstraintFunc,AfterErgo) /*optional*/
         \
    
    
    NEW:
    
       PRODUCT_FLAG(intx,   AliasLevel, 3, JVMFlag::RANGE | JVMFlag::CONSTRAINT,
                            "0 for no aliasing, 1 for oop/field/static/array
    split, "
                            "2 for class split, 3 for unique instances");
        // optional
        FLAG_RANGE(         AliasLevel, 0, 3);
        // optional
        FLAG_CONSTRAINT(    AliasLevel, (void*)AliasLevelConstraintFunc,
    JVMFlag::AfterErgo);
    
    
    
    
    [1]
    http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/hotspot/share/runtime/globals.hpp#l115
    [2]
    http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/hotspot/share/runtime/flags/jvmFlag.cpp#l635
    [3] https://bugs.openjdk.java.net/browse/JDK-7123237
    
    Thanks
    - Ioi