<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    HI,<br>
    <br>
    One way to detect getting out of sync, is to structure the test
    cases for the native verifier such that they can be run by the
    classfile verifier.  Especially use for for test cases developed for
    the latest spec changes.<br>
    <br>
    $.02, Roger<br>
    <br>
    <div class="moz-cite-prefix">On 6/6/25 9:31 PM, Chen Liang wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CABe8uE1vnCEP3jOxYKqCCQjaNyKs0gOnkONjTgFHvxZrN=1ObA@mail.gmail.com">
      
      <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" moz-do-not-send="true" class="moz-txt-link-freetext">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">
          <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>
    </blockquote>
    <br>
  </body>
</html>