Long-term maintenance of verifier

[Brian Goetz]

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.

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.

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.

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.

On 6/5/2025 10:01 PM, Chen Liang wrote:
> Hello,
> 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.
>
> 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?
>
> Regards,
> Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250606/8a2061b1/attachment.htm>