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

[Erik Gahlin]

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.
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