On Thu, 2 Nov 2023 15:52:09 GMT, Thomas Schatzl <[email protected]> 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
