RFR: 8319374: JFR: Remove instrumentation for exception events [v2]

Erik Gahlin egahlin at openjdk.org
Tue Nov 7 02:16:30 UTC 2023

On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin <egahlin at 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.

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

More information about the security-dev mailing list