<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>