RFC 8236988 - Modular Design for JVM Flags

[Chris Newland]

Hi Ioi, Liu Xin,

In case it is any help to this effort I built an open source tool which 
parses VM options.

VMOptionsExplorer https://github.com/chriswhocodes/VMOptionsExplorer 
parses the OpenJDK 6-15 HotSpot sources (as well as OpenJ9 sources and 
the switch outputs from Zing and GraalVM) to build VM switch 
documentation that can be searched and compared here 
https://chriswhocodes.com/vm-options-explorer.html

It also parses intrinsics information from OpenJDK sources and documents 
them here https://chriswhocodes.com/hotspot_intrinsics_jdk11.html

The parsed outputs also power an interactive VM switch inspector 
https://jacoline.dev/inspect

If any of this is useful to your goals please let me know if I can help?

Kind regards,

Chris

--
@chriswhocodes

JITWatch - Log analyser / visualiser for JVM JIT compilers.

VMOptionsExplorer - Look up JVM options and intrinsics.

JaCoLine - Java Command Line Inspector


On 2020-04-12 08:59, Liu, Xin wrote:
> 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