On 24/08/2017 07:33, David Holmes wrote:
Hi Adam,
cc'ing hotspot runtime dev as runtime own JNI and the invocation API -
and some of the problematic code resides in the VM.
Yeah, the hotspot mailing list would be a better place to discuss this
as there are several issues here and several places where HotSpot aborts
the process when initialization fails. It's a long standing issue (going
back 15+ years) that I think is partly because it's not easy to release
all resources and cleanup before CreateJavaVM returns with an error.
This specific case seems like a bug to me as the logic is assuming it
is only ever called by a launcher which it is okay to terminate.
Though to be honest the very existence of the "help" option seems to
me somewhat misguided in a hosted-VM environment. That said, I see
unified logging in 9 also added a terminating "help" option <sigh>.
The agent "help" option case is tricky and would likely need an update
to the JVM TI spec and the Agent_OnLoad return value.
Options processed by the VM will be recognized, while options
processed by the Java launcher will not be. "-version", "-X", "-help"
and numerous others are launcher options. Pure VM options are -XX
options, but the VM also processes some -X flags and, as a result of
jigsaw, now also processes a bunch of module-related flags that are
simple --foo options.
Right because these options need to passed to CreateJavaVM as they are
used when initializing the VM. Using system properties would just repeat
the issues of past (e.g. java.class.path) and require documenting a slew
of system properties (which is complicated at repeating options).
-Alan
