On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin <[email protected]> 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
