RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

Adam Farley8 adam.farley at uk.ibm.com
Thu Feb 15 17:02:39 UTC 2018

On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>> -- Short version --
>> Could a committer please take the fix for JDK-8190187 (full code 
>> in the bug) and:
>> 1) Complete the CSR process for the new JNI Return code.
>> 2) Commit the changes that contain (a) the new return code, and (b) the
>> non-Hotspot code that handles the new code.
> The patches attached to the JIRA issue are missing the changes to the 
> JVM TI spec (jvmti.xml). 

I'm not seeing the JNI return codes in that file. Are you after one of 
dated updates near the bottom?
  <change date="14 February 2018" version="11.0.0">
      Added JNI_SILENT_EXIT return code for early exits without errors.
      java.c's ParseArguments function now sets pret value to 2 for a NULL 
         This allows us to clearly identify when no class was set, but no 
other error has occurred.
         This is undone in java.c's ContinueInNewThread method, so the 
surface behaviour does not change. 

> There is also text to be written for the JNI spec if this proposal goes 
> ahead.

I assume you mean the "RETURNS" section of the JNI_CreateJavaVM 
bit on the invocation.html web page. Something like this?

Returns JNI_OK on success; returns a suitable JNI error code (a negative 
number) on failure.

The sole exception is a silent exit, which returns JNI error code 
This indicates that the VM cannot be used, but that this is the intended 
behaviour for the 
arguments used. E.g. -Xlog:help (which prints help output and then 
destroys the VM)

> I don't agree that the launcher should be looking for 
> "-agentlib:jdwp=help" in the command line as it's just one of many ways 
> that the debugger agent might be started (e.g. -Xrunjdwp:<options>, 

We can avoid that by finding a way around this line in ContinueInNewThread 

return (ret != 0) ? ret : rslt;

I have devised a means to do this, as outlined in the jvmti.xml change 
above. I put the
changes into a recent clone of jdk/jdk, and attached the hg diff, along 
with an improved

If you have Author or Committer privileges, could you add the files to the 
bug please?

>> Backporting would be appreciated, but is optional.
> I don't think these changes are appropriate to backport as they include 
> specification changes/

This is fair.

- Adam

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

More information about the core-libs-dev mailing list