[BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

[Alan Bateman]

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