On Thu, 27 Aug 2026 08:35:34 GMT, Stefan Karlsson <[email protected]> wrote:
> Thanks!
>
> I dug deeper into this and have found that the problem is -Xcheck:jni and the
> `checked_jni_IsSameObject` function:
>
> Without -Xcheck:jni, the code runs the normal `IsSameObject` on the jweak
> handles. `IsSameObject` is intentionally written to use the
> `resolve_no_keepalive`, which as the name suggests, makes sure that the
> resolve operation does not keep the resolved object alive. With -Xcheck:jni,
> this is replaced with `checked_jni_IsSameObject`, which contains this:
>
> ```
> IN_VM(
> /* This JNI function can be used to compare weak global references
> * to nullptr objects. If the handles are valid, but contain nullptr,
> * then don't attempt to validate the object.
> */
> if (obj1 != nullptr && jniCheck::validate_handle(thr, obj1) != nullptr)
> {
> jniCheck::validate_object(thr, obj1);
> }
> if (obj2 != nullptr && jniCheck::validate_handle(thr, obj2) != nullptr)
> {
> jniCheck::validate_object(thr, obj2);
> }
> )
> jboolean result = UNCHECKED()->IsSameObject(env,obj1,obj2);
> ```
>
> `jniCheck::validate_handle` calls `JNIHandles::resolve_external_guard(obj)`,
> which is a resolve with "keepalive" semantics. So, the -Xcheck:jni causes the
> test code agent to artificially keep holding the registered objects alive,
> preventing the GC from clearing out the jweak handles to the otherwise dead
> objects.
So the majors reclaim almost nothing because the validation keeps every
registered object alive, and the big reclaim only comes after the threads die
and the probing stops. given that, is the right fix the no keepalive validation
in the checked wrapper, or should the test side just size for the retained set,
which is what the bump amounts to
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32229#issuecomment-5442856361
