RFR: JDK-8269650: Optimize gc-locker in [Get|Release]StringCritical for latin string

[David Holmes]

On 1/07/2021 7:45 am, Kim Barrett wrote:
> On Wed, 30 Jun 2021 11:55:49 GMT, Hamlin Li <mli at openjdk.org> wrote:
> 
>> Currently, JNI GetStringCritical locks gc locker for all strings including latin and non-latin until ReleaseStringCritical.
>> But for latin, it's not necessary to still lock gc locker after GetStringCritical, as it's copied anyway whether obj pining is supported or not, so it's fine to unlock gc locker after GetStringCritical.
> 
> It turns out that fixing JDK-8269661 involves some code rearrangement that makes it both simple and obvious to not do the gc-locker/pinning in the latin1 case; it would actually make things messier to not include that change.  So unless David's research comes up with something unexpected, I'll probably take over the optimization as part of that bug fix.  Still need to do more testing before sending out a PR.

The is_latin code handling came along with compact strings, and no 
change was made to the GC_locker::lock_critical/unlock_critical pairing.

At that time I can't see that there could be any change. The GC critical 
lock was global/coarse-grained, and all compact strings did was change 
the type of the array it didn't change the way the array was allocated 
or embedded within a Java object.

AFAICS, as Kim has stated in JDK-8269661, any problems here have arisen 
when object-pinning was introduced. Though I'm still unclear whether the 
raw array is actually embedded in the java byte[] instance.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4637
>