Add ability to merge -Xjit/-Xaot opts

[dsouzai]

trafficstars

Related to https://github.com/eclipse-openj9/openj9/issues/12503

Opening this PR for discussion. I figure something like this is a good first step towards allowing multiple -Xjit options by default.

I've introduced the VM option -XX:MergeJitOptions to control whether or not to merge the JIT/AOT options (merging is disabled by default). As the code stands, I allow multiple empty -Xjit:/-Xaot: as long as there's at least one that isn't empty.

Here are some of the results; I put a printf in the options processing code to demonstrate the options that the JIT will parse:

No Options:

 ./jdk11/bin/java -Xshareclasses:none -version

xjitCommandLineOptions=
xaotCommandLineOptions=
...

$ ./jdk11/bin/java -XX:MergeJitOptions -Xshareclasses:none -version

xjitCommandLineOptions=
xaotCommandLineOptions=
...

One JIT option:

$ ./jdk11/bin/java -Xshareclasses:none  -Xjit:version -version

xjitCommandLineOptions=version
xaotCommandLineOptions=
...

$ ./jdk11/bin/java  -XX:MergeJitOptions -Xshareclasses:none  -Xjit:version -version

xjitCommandLineOptions=version
xaotCommandLineOptions=
...

Multiple JIT options:

$ ./jdk11/bin/java -Xshareclasses:none '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -version

xjitCommandLineOptions=version
xaotCommandLineOptions=
...

$ ./jdk11/bin/java -Xshareclasses:none -XX:MergeJitOptions  '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -version

xjitCommandLineOptions=verbose={compilePerformance},vlog=vlog,version
xaotCommandLineOptions=
...

Empty -Xjit::

$ ./jdk11/bin/java  -Xshareclasses:none  -Xjit: -version
JVMJ9VM015W Initialization error for library j9jit29(11): no arguments for -Xjit:
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ ./jdk11/bin/java  -XX:MergeJitOptions -Xshareclasses:none  -Xjit: -version
JVMJ9VM015W Initialization error for library j9jit29(11): no arguments for -Xjit:
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Empty -Xjit: at start:

$ ./jdk11/bin/java -Xshareclasses:none -Xjit: '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -version

xjitCommandLineOptions=version
xaotCommandLineOptions=
...

$ ./jdk11/bin/java -Xshareclasses:none -XX:MergeJitOptions  -Xjit: '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -version

xjitCommandLineOptions=verbose={compilePerformance},vlog=vlog,version
xaotCommandLineOptions=
...

Empty -Xjit: at end:

$ ./jdk11/bin/java -Xshareclasses:none '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -Xjit: -version
JVMJ9VM015W Initialization error for library j9jit29(11): no arguments for -Xjit:
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ ./jdk11/bin/java -Xshareclasses:none  -XX:MergeJitOptions  '-Xjit:verbose={compilePerformance},vlog=vlog' -Xjit:version -Xjit: -version

xjitCommandLineOptions=verbose={compilePerformance},vlog=vlog,version
xaotCommandLineOptions=
...

[klangman]

If this were made the default at some point, it would save me from having to repeatedly explain to people the pitfalls of multiple -Xjit options.

[IBMJimmyk]

Is there a reason for -Xjit: (with the colon) to give an error? Is it possible to just treat it the same as -Xjit (no colon)?

[dsouzai]

Is there a reason for -Xjit: (with the colon) to give an error? Is it possible to just treat it the same as -Xjit (no colon)?

No idea, I assume it was to ensure that the user didn't forget to set an option they may have wanted to? Yeah it's relatively easy to just treat it the same as -Xjit.

[vijaysun-omr]

I had some of the same concerns already expressed (and answered in a subjective sense) in the linked issue around existing users and conflicting options. I saw that in that discussion there was talk of introducing new options instead of (or initially, alongside) -Xjit and -Xaot to mitigate some of the concern. Is this something that you are thinking of doing but this "merge" option is a stepping stone to doing so ?

[dsouzai]

I saw that in that discussion there was talk of introducing new options instead of (or initially, alongside) -Xjit and -Xaot to mitigate some of the concern. Is this something that you are thinking of doing but this "merge" option is a stepping stone to doing so ?

Well sort of. We could add new options even now, and if we detect the new options, we just use those instead of the existing ones, and the new options have merge semantics. The only concern there is that users may have the problem that they have existing -Xjit options scattered over various scripts/envs and it's not as easy for them to go and change everything.

One way of dealing with this is, if the new options are specified, it gets merged with any existing -Xjit options. Another way is to introduce the -XX:MergeJitOption flag to allow users to continue using the existing options but be explicitly aware that the options get merged.

I figured the -XX:MergeJitOption path is one that allows the most flexibility for both us and our users; the users can get used to -Xjit/-Xaot being merged and we can eventually decide to just make the merging default without ever having to change the options that we're all very used to. I'm not saying we can't change the options, but this at least allows to us to decide one way or another while still giving users the benefit of more intuitive options.

[dsouzai]

Closing this in favour of https://github.com/eclipse-openj9/openj9/pull/16133