[BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java
david.holmes at oracle.com
Fri Sep 15 11:03:32 UTC 2017
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
> 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.
More information about the hotspot-runtime-dev