RFR: 8318706: Implementation of JDK-8276094: JEP 423: Region Pinning for G1 [v3]

[Thomas Schatzl]

On Mon, 30 Oct 2023 13:41:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/heapRegion.cpp line 734:
>> 
>>> 732:   // ranges passed in here corresponding to the space between live objects, it is
>>> 733:   // possible that there is a pinned object that is not any more referenced by
>>> 734:   // Java code (only by native).
>> 
>> Can such obj becomes referenced by java again later on? IOW, a pointer passed from native to java.
>
> I do not think so. I will do some more testing about this.

I (still) do not think it is possible after some more re-testing. There are the following situations I can think of:

* string deduplication is a need-to-be-supported case where only the C code may have a reference to a pinned object: thread A critical sections a string, gets the char array address, locking the region containing the char array. Then string dedup goes ahead and replaces the original char array with something else. Now the C code has the only reference to that char array.
There is no API to convert a raw array pointer back to a Java object so destroying the header is fine; unpinning does not need the header.

* there is some other case I can think of that could be problematic, but is actually a spec violation: the array is critical-locked by thread A, then shared with other C code (not critical-unlocked), resumes with Java code that forgets that reference. At some point other C code accesses that locked memory and (hopefully) critically-unlocks it.
Again, there is no API to convert a raw array pointer back to a Java object so destroying the header is fine.

In all other cases I can think of there is always a reference to the encapsulating java object either from the stack frame (when passing in the object into the JNI function they are part of the oop maps) or if you create a new array object (via `New<xxx>Array` and lock it, the VM will add a handle to it.

There is also no API to inspect the array header using the raw pointer (e.g. passing the raw pointer to `GetArrayLength`  - doesn't compile as it expects a `jarray`, and in debug VMs there is actually a check that the passed argument is something that resembles a handle), so modifications are already invalid, and the change is fine imo.

hth,
  Thomas

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16342#discussion_r1376560372