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

[Ioi Lam]

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25522/files
  - new: https://git.openjdk.org/jdk/pull/25522/files/2a5bdd82..cd41e2ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25522&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25522&range=08-09

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25522/head:pull/25522

PR: https://git.openjdk.org/jdk/pull/25522