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

[Albert Mingkun Yang]

On Thu, 2 Nov 2023 15:52:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> 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
>
> Here is some example (pseudo-) code for the first case mentioned above that should be valid JNI code:
> 
> 
> Java code:
> 
> String x = ...;
> native_f1(x);
> [ some java code, x.chars gets deduplicated, its char array pointing to somewhere else now. Now native code is the only one having a reference to the old char array ]
> native_f2();
> 
> ----------- sample native code:
> 
> void native_f1(jobject jstring) {
>    global_string = NewGlobalRef(jstring);
>    global_raw_chars = GetStringChars(global_string);
> }
> 
> void native_f2() {
>    ReleaseStringChars(global_string, global_raw_chars);
>    DeleteGlobalRef(global_string);
> }

> string deduplication is a need-to-be-supported case...

OK, so this is the only valid scenario where a type-array should be kept live even though it's not reachable from GC's perspective. Could you describe it in the comment?

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

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