RFR: 8230043: Lazily load libverify

Harold Seigel harold.seigel at oracle.com
Fri Aug 23 16:43:22 UTC 2019

Hi Claes,

thanks for doing this.  I have a couple of questions.

1. Is line 87 in verifier.cpp trying to load libverify, if so, why?

    87   if (!os::dll_locate_lib(buffer, sizeof(buffer),
    Arguments::get_dll_dir(), "verify"))

2. Did the change intend to remove the SerializePage_lock from 
mutexLocker.cpp ?

3. Did the change intend to remove mutex ParkerFreeList_lock from 
mutexLocker.hpp ?

Thanks, Harold

On 8/23/2019 9:08 AM, 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 hotspot-runtime-dev mailing list