Should Class.name field be @Stable?

- liangchenblue at gmail.com
Sun Dec 24 16:20:06 UTC 2023


After another peek, I find a few other fields in Class can benefit from @Stable
too:
classData, packageName, allPermDomain, reflectionFactory, classValueMap.
They are all accessed with benign race.

There are other fields I'm interested in promoting to @Stable, most
notably enumConstants and enumConstantsDirectory; they use mutable data
structures and need extra release/store (LoadStore+StoreStore) fences. In
addition, I am not sure if Class redefinition would tamper these fields.
Thus, I am also CC'ing serviceability-dev for a confirmation. Same question
applies to genericInfo field, which is not protected as part of
ReflectionData (that explicitly supports JVMTI redefinitions) somehow.

Curious, Chen

On Tue, Dec 19, 2023 at 7:38 AM - <liangchenblue at gmail.com> wrote:

> Thanks for the analysis. I know that in a race, VM is free to promote any
> non-null value to a constant. Thus using @Stable is totally safe;
> similarly, the reflectionFactory is @Stable and created with a benign race.
> I'll create an RFE then.
>
>
> On Tue, Dec 19, 2023, 3:40 AM Jaikiran Pai <jai.forums2013 at gmail.com>
> wrote:
>
>> Hello Chen,
>>
>> Looking at the implementation of java.lang.Class.getName(), which then
>> triggers the hotspot code to initialize this "name" field, I suspect there
>> will be a (harmless) race in the hotspot implementation where more than one
>> thread could end up writing the "name" field (with the same value of
>> course)
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L1237.
>> I don't know how the JVM would then react if such a field is marked @Stable
>> (the javadoc of @Stable states that the behaviour is such cases is
>> undefined).
>>
>> -Jaikiran
>> On 16/12/23 8:37 pm, - wrote:
>>
>> Hello,
>> I just noticed the Class.name field is mutable but not @Stable, meaning
>> `Class.getName()` calls are not eligible for constant folding.
>>
>> The last update to this field is in 2019 in JDK-8216302 when the field
>> initialization was done directly by a write from hotspot code (for the
>> class name is interned anyways, though interning limits scalability of
>> hidden classes)
>>
>> Would it be a good idea to submit a patch to mark this field @Stable?
>> Given class names may be frequently used to quickly identify a class, to
>> create descriptors.
>>
>> Chen Liang
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231224/74275d55/attachment.htm>


More information about the core-libs-dev mailing list