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

[Adam Farley8]

Hi Alan, David, and Tom,

First, thanks again for your efforts on this. As a new guy to OpenJDK
contributions, it means a lot to see so much progress on this so quickly. 
:)


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

According to the JNI spec, it is not possible (yet) to create a second VM
in the same thread as the first. 

There is also a bug (dup'd against another bug I don't have the access 
for) 
which states that even a successful VM creation+destruction won't permit
a second VM to be created.

https://bugs.openjdk.java.net/browse/JDK-4712793

Both of these seem to imply that making a new VM after a failed 
VM-creation
(in the same thread) is unsupported behaviour.

So is it important to release all resources and cleanup, given that we 
won't
be trying to create a new VM in this thread? By "important" I mean "more
important than exiting with a return code and allowing the user's code to 
finish".

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

To clarify, the agent "help" option is only an example of this problem.
There are 19 locations both within and without hotspot that call exit(0)
directly, plus more places where exit is passed a variable that can be
0 (e.g. the aforementioned agent "help", which calls the forceExit 
function
with an argument of 0, which calls exit(arg) in turn).

I understand that your comment was intended as an effort to effect a fix 
for this specific instance of the problem. I wanted to make sure we kept 
sight of the wider problem, as ideally we'd come up with an ideal solution 

that could be applied to all cases.

My thought on this was a unique return code that tells the user's code 
that the VM is not in a usable state, but that no error has occurred. This
should be a negative code (so the usual x<0 check will prevent the user's
code from using the VM), but it shouldn't be one of the existing JNI 
codes;
all of which seem to indicate either:

a) The VM is fine and can be used (0).
or
b) The VM is not fine because an error occurred (-1 to -6).

Ideally we need a c) The VM is not fine, but no error has occurred.

Or is there another solution to the exit(0) problem? Other than putting a 
copy 
of the rest of your code on the exit hook, I mean.

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