RFR: JDK-8269650: Optimize gc-locker in [Get|Release]StringCritical for latin string
David Holmes
david.holmes at oracle.com
Wed Jun 30 22:39:57 UTC 2021
On 30/06/2021 10:35 pm, Thomas Schatzl 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.
>
> Actually I think the *String* object can be unlocked regardless of `is_latin1` or not. The code returns the *char array* that the native code is going to process after all - which is not locked *at all* but probably should be. I filed [JDK-8269661](https://bugs.openjdk.java.net/browse/JDK-8269661) for this.
I admit I do not know how String objects are laid out since compact
strings came along but IIRC before that the char* pointed to an actual
array embedded in the String's value, and so the String (and its value
array) had to be pinned/locked.
David
> Which should probably be fixed first, because if the change correctly unconditionally unlocked the String object, Shenandoah would start to fail.
> It probably works at this time because the String object and the char array are typically located in the same region anyway.
>
> -------------
>
> Changes requested by tschatzl (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/4637
>
More information about the hotspot-dev
mailing list