<div dir="ltr">After another peek, I find a few other fields in Class can benefit from <a class="gmail_plusreply" id="plusReplyChip-0">@Stable too:</a><div>classData, packageName, allPermDomain, reflectionFactory, classValueMap. They are all accessed with benign race.</div><div><br></div><div>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.</div><div><a class="gmail_plusreply"><br></a></div><div>Curious, Chen</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 19, 2023 at 7:38 AM - <<a href="mailto:liangchenblue@gmail.com">liangchenblue@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 19, 2023, 3:40 AM Jaikiran Pai <<a href="mailto:jai.forums2013@gmail.com" target="_blank">jai.forums2013@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hello Chen,</p>
<p>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)
<a href="https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L1237" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L1237</a>.
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).<br>
</p>
<p>-Jaikiran<br>
</p>
On 16/12/23 8:37 pm, - wrote:<br>
<blockquote type="cite">
<div dir="ltr">Hello,
<div>I just noticed the Class.name field is mutable but not
@Stable, meaning `Class.getName()` calls are not eligible for
constant folding.</div>
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Chen Liang<br>
<a class="gmail_plusreply" rel="noreferrer"><br>
</a></div>
</div>
</blockquote>
</div>
</blockquote></div>
</blockquote></div>