On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin <egah...@openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44: >> >>> 42: >>> 43: public static void traceError(Class<?> clazz, String message) { >>> 44: if (OutOfMemoryError.class.isAssignableFrom(clazz)) { >> >> StackOverflowError is likely problematic too, maybe it should be >> VirtualMachineError. > > I remember asking the same question ten years ago, when Nils did the original > implementation, but I think it was only needed for OOM, because it creates an > infinite loop when the event object was allocated, which resulted in a > StackOverflowError instead OOM. > > Some OOM tests failed with JFR enabled. > > The event object allocation has been removed, but I think we can run into the > allocation recursion by other means. I looked into it a few years ago, but I > don't remember exactly why it failed. > > If a SOE happens, I think we are fine. There is something that prevents > infinite recursion when the SOE object is created. Perhaps it is > preallocated? I prefer to not change the behavior, at least not in this PR. I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579 Regardless of outcome, It would be good to document the results of the investigation in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384263589