JDK-8336329 : Add an internal Java-callable function to raise a fatal error
  • Type: Enhancement
  • Component: core-libs
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • Submitted: 2024-07-12
  • Updated: 2024-08-19
Related Reports
Relates :  
Description
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.
Comments
The foreign function implementation in Java allows for upcalls - invocations that originate from the native code into some java code. If the java code invoked from such an upcall throws any exception, then the FFM integration layer in the JDK currently will System.exit(1) the java runtime along with the stack trace of the thread from which that exit happened and a message on System.err which says "Unrecoverable uncaught exception encountered. The VM will now exit". https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java#L307 Based on my discussion with the panama team, this current implementation to System.exit(1) from this layer is intentional and unavoidable given the nature of such calls. I am merely adding this comment here to help decide whether, if we implement the enhancement noted in this current JBS issue, then can/should the FFM use case be accomodated in some manner.
19-08-2024