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 build-dev
mailing list