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