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
