-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
None
There are a couple places in runtime code written in Java that call System.exit():
https://github.com/openjdk/jdk/blob/jdk-22-ga/src/java.base/share/classes/jdk/internal/vm/Continuation.java#L270
https://github.com/openjdk/jdk/blob/jdk-22-ga/src/java.base/share/classes/jdk/internal/ref/Cleaner.java#L151
Exiting in this manner is odd. Note that System.exit() runs shutdown hooks and waits for them to terminate before exiting the JVM. It's unlikely that a normal exit was intended here. In both cases a stack trace is printed before exit() is called. What was probably intended was something like an "assertion failure" or "abnormal exit" or "fatal error" that produces some diagnostic information that is useful for debugging the situation.
Runtime.halt() is probably not suitable for this, as it simply halts the JVM immediately without emitting any diagnostic information.
What would seem useful is a new, internal interface, callable from Java code, that triggers a bunch of diagnostic output followed by immediate JVM termination. Something like the VMError::report might be suitable ("A fatal error has been detected..." with a pointer to hs_err_pidNNNNN.log containing a bunch of diagnostic information.) This isn't exactly right though, as this would be called from Java code, more Java-specific info such as a thread dump might be reasonable to include.
The code base should be searched for other uses of System.exit() or possibly Runtime.halt(). In addition, there are some cases where InternalError is thrown explicitly from Java code. If this is thrown from Java runtime code (as opposed to library code) then it might be a candidate for replacement with a fatal error call.
https://github.com/openjdk/jdk/blob/jdk-22-ga/src/java.base/share/classes/jdk/internal/vm/Continuation.java#L270
https://github.com/openjdk/jdk/blob/jdk-22-ga/src/java.base/share/classes/jdk/internal/ref/Cleaner.java#L151
Exiting in this manner is odd. Note that System.exit() runs shutdown hooks and waits for them to terminate before exiting the JVM. It's unlikely that a normal exit was intended here. In both cases a stack trace is printed before exit() is called. What was probably intended was something like an "assertion failure" or "abnormal exit" or "fatal error" that produces some diagnostic information that is useful for debugging the situation.
Runtime.halt() is probably not suitable for this, as it simply halts the JVM immediately without emitting any diagnostic information.
What would seem useful is a new, internal interface, callable from Java code, that triggers a bunch of diagnostic output followed by immediate JVM termination. Something like the VMError::report might be suitable ("A fatal error has been detected..." with a pointer to hs_err_pidNNNNN.log containing a bunch of diagnostic information.) This isn't exactly right though, as this would be called from Java code, more Java-specific info such as a thread dump might be reasonable to include.
The code base should be searched for other uses of System.exit() or possibly Runtime.halt(). In addition, there are some cases where InternalError is thrown explicitly from Java code. If this is thrown from Java runtime code (as opposed to library code) then it might be a candidate for replacement with a fatal error call.
- relates to
-
JDK-4954921 (ref) If a cleaner throws an exception then the VM should exit
-
- Resolved
-