<div dir="ltr">Thanks for the clarification. I totally agree with this decision of staying on track of Option 2, as verification in the ClassFile API is mostly a debug tool instead of a performance sensitive component.<div><br></div><div>That said, I noted we are a bit out of sync - for example, JDK-8350029 is applied to runtime recently and it is clearly not in the ClassFile API. On the mainline, lack of synchronization is not that big a deal as we have only minor updates; however, project valhalla introduces strict fields, which makes this synchronization more necessary, especially that otherwise strict fields and early_larval_frame will be regarded as verification errors.</div><div><br></div><div>We can probably start our updating on mainline so we can help valhalla. We currently can claim the CF verifier lacks any patch after the initial 6/10/2022 publication in jdk-sandbox, but it is still helpful to know which commit or which JDK release of verifier.cpp was the copy based off - we can probably drop this "up-to-date-to-tag/commit" info in our shadow so we can sync more easily.</div><div><br></div><div>Adam, do you know about the exact fork version of the verifier code? Once we have a point in history, it's quite easy to check the hotspot commits and see if we need to update our copy accordingly.</div><div><br></div><div>Regards, Chen</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jun 6, 2025 at 11:46 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.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>
    <font size="4" face="monospace">We had some discussions about this
      when the verifier was hand-translated from the C++ code.  At the
      time, some care was taken to ensure that we _not_
      refactor-as-we-go, to preserve some structural similarity with the
      C++ code, so that deltas in the C++ code could be forward-ported. 
      <br>
      <br>
      We were initially skeptical that duplicating this code would work,
      but it turned out to be quite effective.  Of course, long-term
      maintenance has to be part of the story.<br>
      <br>
      Going forward, I think we are still in the phase where the "keep
      it synchronized" strategy (Adam's #2) can work.  We have to be
      diligent to not make stylistic changes as we go, and keep up with
      changes in the runtime.  <br>
      <br>
      Long term, I think there may be something we can do with #1, now
      that Panama is finalized, but that is not enough.  While calling
      into the C++ code is now more practical, but that's not enough;
      the runtime code is designed solely to support on-the-fly analysis
      during class loading.  Some refactoring of the C++ API, undertaken
      by the runtime team, would be needed to allow it to serve multiple
      masters.  <br>
    </font><br>
    <div>On 6/5/2025 10:01 PM, Chen Liang wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hello,
        <div>I have noted that the classfile API's copy of migrated
          verifier seems to naturally diverge from the c++ code: for
          example, JDK-8350029 that restricts invokespecial to not allow
          invoking arbitrary interface methods is not shadowed to the
          classfile verifier. This problem will only get more serious
          once strict fields are added. Meanwhile, people expect
          ClassFile.verify to be up-to-date with the runtime verifier.</div>
        <div><br>
        </div>
        <div>What should we do to resolve this discrepancy? Should we
          have a separately maintained Java-based verifier implementing
          JVMS 4.10, or should we just increase our frequency of
          synchronizing with runtime?</div>
        <div><br>
        </div>
        <div>Regards,</div>
        <div>Chen Liang</div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>