RFR: 8230043: Lazily load libverify

David Holmes david.holmes at oracle.com
Mon Aug 26 05:12:15 UTC 2019


Hi Claes,

This cleanup all appears fine to me.

The unused Mutex declarations might be better handled in a separate RFE 
but I don't insist. You could file the RFE and still fix together in 
this one changeset.

> Testing: tier1-4

Do you know which tests actually test the older verifier? Just thinking 
that it might be a good idea to make them more obvious.

Thanks,
David

On 23/08/2019 11:08 pm, Claes Redestad wrote:
> Hi,
> 
> please review this cleanup to untangle the old bytecode verifier
> (libverify). It's currently linked and loaded eagerly and early during
> bootstrap.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8230043
> 
> - removes dependency on libverify from libjava by moving the 
> check_format.c functions into libjava (they don't need to be exported 
> via JNI)
> - fixed build to not link libjava with libverify
> - removes the eager initialization of libverify in
> os::native_java_library
> - removes the verify_stubs and directs verifier.cpp to load and call 
> VerifyClassForMajorVersion in libverify directly. The initialization
> is synchronized on a new mutex, Verify_lock
> - remove the unused VerifyClass entry point and simplify code in the
> verifier by removing some indirections
> 
> Testing: tier1-4
> 
> Thanks!
> 
> /Claes


More information about the core-libs-dev mailing list