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

[David Holmes]

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.

On 24/08/2017 1:54 AM, Adam Farley8 wrote:
> Hi All,
> 
> Problem: Several of Java's "c" files call exit(0) if you pass certain
> command-line options to JNI_CreateJavaVM, which can terminate the C++ code
> JNI users use to initialise the JVM.
> 
> Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses
> the option "-agentlib:jdwp=help", Java's c files will print the needed
> help output and call exit(0).
> 
> Result: Your C++ code is terminated on this line, and a return code of 0
> is produced.
> 
> Issues:
> 
> Issue 1: The exit(0) prevents your code from doing anything useful after
> the JNI_CreateJavaVM call.
> Issue 2: The exit(0) indicates to anything monitoring your C++ code that
> your code exited normally, even though it was terminated mid-way-through.
> Issue 3: This return code is useless to us, as a 0 can indicate the VM
> started correctly, or it can indicate the VM was terminated due to one or
> more of these command-line options.
> Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of
> them appear to cover this scenario.

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>.

More generally it must be noted that the VM itself will often abort the 
hosting process, upon encountering an initialization error, rather than 
causing JNI_CreateJavaVM to return JNI_ERR.

But I think we can certainly do better with "help" options, to not 
(necessarily) terminate the initialization process and abort the VM.

> 
> Proposed solutions:
> 
> PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT"
> return code, so the C++ code knows a VM was not created, but that it isn't
> an error.

I'm not sure a new code is needed ... especially if initialization of 
the VM continues. Though if we really want the VM to abandon 
initialization when it sees certain flags then that needs to be spec'd 
into JNI_CreateJavaVM.

> PS2: We should identify a list of the command-line options that produce
> this behaviour via the JNI. (not all of the "help" options are recognised
> by the JNI interface. E.g. -version and -help produce a JNI_ERR and an
> "Option not recognised" message)

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.

If writing a custom launcher, or something that acts like one, you need 
to be able to process all of the command-line flags and know which ones 
get passed through to the JVM and which do not. If you are trying to be 
compatible with the OpenJDK launcher then you'll need to be prepared to 
handle all of its arguments.

JNI itself should not be aware of any such arguments - it should simply 
be allowed for JNI_CreateJavaVM to "fail" when it encounters them.

> PS3: We should replace these annoying exit(0) calls with code that returns
> "JNI_SILENT_EXIT", so the C++ code has a chance to finish.

We should certainly look at getting rid of the exit() calls. Ideally no 
VM related flag would be of the "report and terminate" type, as the 
termination aspect really belongs in the launcher. I can imagine a 
launcher using Dcmds to retrieve "help" strings from subsystems rather 
than having actual "help" options processed by the VM (somewhat similar 
t how -version is handled: create VM, extract version info, detach VM. 
exit launcher). That said it would be somewhat awkward, for example, if 
the launcher processed -Xlog:help, but the VM processed all other -Xlog 
arguments.

Cheers,
David

> 
> Best Regards
> 
> Adam Farley
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>