RFR: 8344165: Trace exceptions with a complete call-stack [v10]

[David Holmes]

On Fri, 20 Jun 2025 21:31:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR makes it easier to analyze exceptions without modifying the JVM or the app to print call stacks:
>> 
>> Excerpt from the test case ExceptionsTest.java. 
>> 
>> 
>> [0.042s][info][exceptions] Exception <a 'java/lang/RuntimeException'{0x0000000474019530}: Test exception 1 for logging>
>> [                        ]  thrown in interpreter method <{method} {0x000079e52c4005b0} 'bar' '()V' in 'ExceptionsTest$InternalClass'>
>> [                        ]  at bci 9 for thread 0x000079e58c02c7b0 (main)
>> [0.042s][info][exceptions,stacktrace] Exception <a 'java/lang/RuntimeException'{0x0000000474019530}: Test exception 1 for logging>
>> [0.042s][info][exceptions,stacktrace] 	at ExceptionsTest$InternalClass.bar(ExceptionsTest.java:110)
>> [0.042s][info][exceptions,stacktrace] 	at ExceptionsTest$InternalClass.foo(ExceptionsTest.java:105)
>> [0.042s][info][exceptions,stacktrace] 	at ExceptionsTest$InternalClass.main(ExceptionsTest.java:100)
>> [0.042s][info][exceptions           ] Found matching handler for exception of type "java.lang.RuntimeException" in method "bar" at BCI: 10
>> Exception 1 caught.
>> 
>> 
>> - Note that the old `[exceptions]` log  is triggered by `InterpreterRuntime::exception_handler_for_exception()` and prints one level of the stack while the interpreter is looking for a handler. However, once a handler is found (inside `bar()`), the `[exceptions]` log terminates, and we do not know about the `foo()` or `main()` methods.
>> 
>> - The `[exceptions,stacktrace]` log is printed only when an exception is thrown:
>>     - By an `_athrow` bytecode. See comments around `Exceptions::log_exception_stacktrace(Handle exception, methodHandle method, int bci)`
>>     - By native code in Exceptions::special_exception() and  and Exceptions::_throw()).
>> 
>> **Concurrent Exceptions**
>> 
>> Neither the old  `[exceptions]` or the new `[exceptions,stacktrace]` logs distinguish between multiple exceptions that are thrown and handled concurrently. The users should use something like `-Xlog:exceptions,exceptions+stack::tags,tid` to include the thread ID into the log output, and use an external tool (such as a script) to demultiplex the logs.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments; Also, use ProcessTools.executeProcess() to log the output in files

This simplified version of the fix is also okay. If people have issues using it then we can address those as they arise.

A couple of nits below.

Thanks

src/hotspot/share/utilities/exceptions.cpp line 156:

> 154:     // tracing (do this up front - so it works during boot strapping)
> 155:     // Note, the print_value_string() argument is not called unless logging is enabled!
> 156:     log_info(exceptions)("Exception <%.*s%s%.*s> (" PTR_FORMAT ") \n"

The way `log_info` et al. work already implicitly checks if the logging is enabled and otherwise it doesn't evaluate anything else, so there is no need to make this change here. In the previous case there was some extra code that is now no longer executed unless needed so that was okay. The key point is that in general you do not need to guard simple `log_xxx(foo)(...)` statements with `log_is_enabled`.

src/hotspot/share/utilities/exceptions.cpp line 637:

> 635:   if (!method->is_native() && (Bytecodes::Code) *method->bcp_from(bci) == Bytecodes::_athrow) {
> 636:     // TODO: it would be nice to filter out exceptions re-thrown by finally blocks (which include
> 637:     // try-with-resource statements):

This mega-comment really doesn't belong here. Please ensure this discussion is in JBS and just use a short comment here e.g.

// TODO: try to find a way to avoid repeated stacktraces when an exception gets re-thrown by a finally block

-------------

PR Review: https://git.openjdk.org/jdk/pull/25522#pullrequestreview-2948757369
PR Review Comment: https://git.openjdk.org/jdk/pull/25522#discussion_r2160780013
PR Review Comment: https://git.openjdk.org/jdk/pull/25522#discussion_r2160784505