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

[David Holmes]

On 15/09/2017 8:17 PM, Alan Bateman wrote:
> On 15/09/2017 02:47, David Holmes wrote:
>> Hi Adam,
>>
>> I am still very much torn over this one. I think the idea of 
>> print-and-exit flags for a potentially hosted library like the JVM is 
>> just wrong - we should never have done that, but we did. Fixing that 
>> by moving the flags to the launcher is far from trivial**. Endorsing 
>> and encouraging these sorts of flag by adding JNI support seems to be 
>> sending the wrong message.
>>
>> ** I can envisage a "help xxx" Dcmd that can read back the info from 
>> the VM. The launcher can send the Dcmd, print the output and exit. The 
>> launcher would not need to know what the xxx values mean, but would 
>> have to intercept the existing ones.
>>
>> Another option is just to be aware of these flags (are there more than 
>> jdwp and Xlog?) and deal with them specially in your custom launcher - 
>> either filter them out and ignore them, or else launch the VM in its 
>> own process to respond to them.
>>
>> Any changes to the JNI specification need to go through the CSR process.
> Yes, it would require an update to the JNI spec, also a change to the 
> JVM TI spec where Agent_OnLoad returning a non-0 value is specified to 
> terminates the VM. The name and value needs discussion too, esp. as the 
> JNI spec uses negative values for failure.
> 
> In any case, I'm also torn over this one as it's a corner case that is 
> only interesting for custom launchers that load agents with options that 
> print usage messages. It wouldn't be hard to have the Agent_OnLoad 
> specify a printf hook that the agent could use for output although there 
> are complications with agents such as JDWP that also announce their 
> transport end point. Beyond that there is still the issue of the custom 
> launcher that would need to know to destroy the VM without reporting an 
> error.
> 
> So what happened to the more meaty part to this which is fixing the 
> various cases in HotSpot that terminate the process during 
> initialization? I would expect some progress could be made on those 
> cases while trying to decide whether to rev the JNI and JVM TI specs to 
> cover the help case.

Trying to eliminate the vm_exit_during_initialization paths in hotspot 
is a huge undertaking IMHO.

David

> 
> -Alan