On Mon, 9 Mar 2026 16:05:40 GMT, Joel Sikström <[email protected]> wrote:

>> Hello,
>> 
>> In java.instrument native libinstrument JavaExceptions.c, the fallback 
>> InternalError static sFallbackInternalError is created during VM or agent 
>> initialization and is stored as a JNI local reference (NewObject via HotSpot 
>> jni_NewObject to JNIHandles::make_local). Agent initialization runs under 
>> JvmtiThreadEventMark in JvmtiExport::post_vm_initialized, which establishes 
>> a JNI handle scope that is popped when the mark goes out of scope after the 
>> VMInit callback returns. This allows sFallbackInternalError to outlive the 
>> local handle block it was allocated in, leaving a dangling reference in a 
>> static variable. In low-memory conditions, when creating a new InternalError 
>> fails and the code falls back to sFallbackInternalError, the stored handle 
>> has likely been cleared or reused, causing fallback exception creation or 
>> throwing to fail.
>> 
>> To make the fallback InternalError persistent, I suggest we allocate it in 
>> global storage using JNI's NewGlobalRef. Since this fallback should be 
>> always present, I don't think we should deallocate it. Simultaneously, I 
>> suggest we enhance the return types a bit by using JNI_FALSE and JNI_TRUE 
>> instead of the implicitly converted value from the comparison check. The 
>> first NULL-check for the localRef isn't strictly needed as NewGlobalRef is 
>> well-defined in taking in NULL as an argument, but I suggest we be explicit 
>> here to make it easier for the reader to understand what's going on.
>> 
>> Testing:
>> * Local testing in lldb to see that we always have access to a well-defined 
>> fallback in different calls to JPLISAgent.c functions.
>> * Running through Oracle's tier1-4
>
> Joel Sikström has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update copyright year

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/30141#pullrequestreview-3916930741

Reply via email to