While the output of -Xlog:exceptions is already very helpful in diagnosing bugs, sometimes it helps to know where an exception is coming from within the VM.
For example, the CompileBroker does String constant resolution[1] and in JDK tests that stress OutOfMemoryError handling, this resolution can result in "spurious" OOMEs that cause test failure, especially when running -Xcomp. This was discovered by enhancing -Xlog:exceptions output to include a native stack trace when throwing an OOME (see dump_oome_native_stack.patch).
Such a general purpose facility can help with diagnosing other "spurious" exceptions. It could be modeled afterJDK-8193513 with a new flag:
product(ccstr, LogExceptionNativeStackFor, nullptr, \
"Enhance -Xlog:exceptions to include a native stack trace for " \
"exceptions whose qualified name in internal format " \
"(e.g., java/lang/OutOfMemoryError) contains this string.") \
[1] https://github.com/openjdk/jdk/blob/000f4d8d156a48939fd29f8b4dd84b3dfd7d9d95/src/hotspot/share/compiler/compileBroker.cpp#L1400
For example, the CompileBroker does String constant resolution[1] and in JDK tests that stress OutOfMemoryError handling, this resolution can result in "spurious" OOMEs that cause test failure, especially when running -Xcomp. This was discovered by enhancing -Xlog:exceptions output to include a native stack trace when throwing an OOME (see dump_oome_native_stack.patch).
Such a general purpose facility can help with diagnosing other "spurious" exceptions. It could be modeled after
product(ccstr, LogExceptionNativeStackFor, nullptr, \
"Enhance -Xlog:exceptions to include a native stack trace for " \
"exceptions whose qualified name in internal format " \
"(e.g., java/lang/OutOfMemoryError) contains this string.") \
[1] https://github.com/openjdk/jdk/blob/000f4d8d156a48939fd29f8b4dd84b3dfd7d9d95/src/hotspot/share/compiler/compileBroker.cpp#L1400
- relates to
-
JDK-8193513 add support for printing a stack trace on class loading
-
- Resolved
-