RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java
adam.farley at uk.ibm.com
Tue Feb 27 15:04:48 UTC 2018
Resending. Bump. :)
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
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>,
> _JAVA_TOOLS_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
>> 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.
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