P4 Description
There are a number of JVM flags that serve to "do X" then terminate the process by calling exit(0), for example:
-agentlib:jdwp=help
-Xlog:help
-Xdump
If these options are passed through from a host process using the JNI invocation API the host process gets terminated by the exit(0) - which is wrong.
There are a number of ways to handle this and the issues was discussed extensively here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048960.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049196.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049498.html
Here is the summary from Adam Farley:
1) Exit(0) (during VM startup) is a big bug because it imitates successful completion of external cpp code accessing JNI methods.
2) One solution for (1) is to specify a new return code for JNI.
3) The supplied code (diff) generates, facilitates, and handles that return code for the exit(0) scenario: -agentlib:jdwp=help
4) The exit(0) problem (in general) is worth fixing, however we may choose not to support the use of this new code in the jdwp example case.
5) The supplied test confirms that the supplied code works (run via unzip, and then bash TestStart.sh <path to jdk home dir that contains bin dir>).
6) To implement this new return code, plus the code that handles it, we would need to follow the CSR process to modify the JNI spec.
7) To implement the jdwp scenario fix, if we choose to support it at all, we would also need to use the CSR process the JVM TI spec.
8) To address all of the worst instances of exit(0), we would need to search for exit(0) and raise a bug for each significant one (or group).
9) To solve (8) in one bug would be a lot of work, arguably too much work for a single bug.
10) If the new return code is identified as the appropriate solution to this problem, we will need to agree on the right name and return code value.
Also, here's a shortlist of the main questions I recall being raised here, plus answers people have given.
A) What are the potential solutions for the exit(0) problem?
i) New JNI Return Code.
ii) Remove the info-only options, at least via the JNI, and return a standard error code if they are used.
iii) Remove the info-only options, at least via the JNI, and filter them out if they are used.
iv) Retain existing behaviour, and document a need for the user to filter out help options before starting the VM via the JNI.
B) What are the criteria for the "Best" solution?
i) It must prevent "exit(0)" calls.
ii) It must be proven to work.
iii) It should require minimal (none, ideally) behaviour change from the java.exe user.
iv) It should allow the external cpp code accessing the JNI to complete normally, without being prematurely terminated.
C) Which solutions meet the (B) criteria?
i) Both the "new return code" and the "remove info-only options" solutions meet the (B) criteria.
D) Is it right to have any "Do X and then exit." arguments at all, and (if no) what would be the alternatives?
i) Given the VM is a loadable shared library the answer should be No. We should not have any "Do X and then exit"
arguments. The alternatives would be a mix of:
- added Dcmds to "Do X"
- added launcher smarts to recognize options that need a Dcmd and "then exit".
Note from David:
I find the notion of "help" options problematic for a shared library. But I don't have a good answer for how else to document things. That all said I think this ship has sailed and we're unlikely to want to invest the time and effort in trying to clean this up this way.
The patch/diff referred to is attached along with a test.
While there are potentially launcher issues here the main issue is JNI and the JNI specification, so this is filed against hotspot->runtime
P.S. The "RETURNS" section of the JNI_CreateJavaVM
bit on the invocation.html web page will need to be amended
to something like this.
```
RETURNS:
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 JNI_SILENT_EXIT.
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)
```
-agentlib:jdwp=help
-Xlog:help
-Xdump
If these options are passed through from a host process using the JNI invocation API the host process gets terminated by the exit(0) - which is wrong.
There are a number of ways to handle this and the issues was discussed extensively here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048960.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049196.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049498.html
Here is the summary from Adam Farley:
1) Exit(0) (during VM startup) is a big bug because it imitates successful completion of external cpp code accessing JNI methods.
2) One solution for (1) is to specify a new return code for JNI.
3) The supplied code (diff) generates, facilitates, and handles that return code for the exit(0) scenario: -agentlib:jdwp=help
4) The exit(0) problem (in general) is worth fixing, however we may choose not to support the use of this new code in the jdwp example case.
5) The supplied test confirms that the supplied code works (run via unzip, and then bash TestStart.sh <path to jdk home dir that contains bin dir>).
6) To implement this new return code, plus the code that handles it, we would need to follow the CSR process to modify the JNI spec.
7) To implement the jdwp scenario fix, if we choose to support it at all, we would also need to use the CSR process the JVM TI spec.
8) To address all of the worst instances of exit(0), we would need to search for exit(0) and raise a bug for each significant one (or group).
9) To solve (8) in one bug would be a lot of work, arguably too much work for a single bug.
10) If the new return code is identified as the appropriate solution to this problem, we will need to agree on the right name and return code value.
Also, here's a shortlist of the main questions I recall being raised here, plus answers people have given.
A) What are the potential solutions for the exit(0) problem?
i) New JNI Return Code.
ii) Remove the info-only options, at least via the JNI, and return a standard error code if they are used.
iii) Remove the info-only options, at least via the JNI, and filter them out if they are used.
iv) Retain existing behaviour, and document a need for the user to filter out help options before starting the VM via the JNI.
B) What are the criteria for the "Best" solution?
i) It must prevent "exit(0)" calls.
ii) It must be proven to work.
iii) It should require minimal (none, ideally) behaviour change from the java.exe user.
iv) It should allow the external cpp code accessing the JNI to complete normally, without being prematurely terminated.
C) Which solutions meet the (B) criteria?
i) Both the "new return code" and the "remove info-only options" solutions meet the (B) criteria.
D) Is it right to have any "Do X and then exit." arguments at all, and (if no) what would be the alternatives?
i) Given the VM is a loadable shared library the answer should be No. We should not have any "Do X and then exit"
arguments. The alternatives would be a mix of:
- added Dcmds to "Do X"
- added launcher smarts to recognize options that need a Dcmd and "then exit".
Note from David:
I find the notion of "help" options problematic for a shared library. But I don't have a good answer for how else to document things. That all said I think this ship has sailed and we're unlikely to want to invest the time and effort in trying to clean this up this way.
The patch/diff referred to is attached along with a test.
While there are potentially launcher issues here the main issue is JNI and the JNI specification, so this is filed against hotspot->runtime
P.S. The "RETURNS" section of the JNI_CreateJavaVM
bit on the invocation.html web page will need to be amended
to something like this.
```
RETURNS:
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 JNI_SILENT_EXIT.
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)
```