RFR: 8230043: Lazily load libverify

Claes Redestad claes.redestad at oracle.com
Sun Aug 25 19:35:52 UTC 2019

Hi Alan,

On 2019-08-24 10:00, Alan Bateman wrote:
> On 23/08/2019 14:08, 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
> This mostly looks good to me.

thanks for looking at this.

> One thing that I'm wondering if whether the fixClassname usages could be 
> replaced with verifyFixClassname as the former will abort the replace 
> when a UTF-8 sequence can't be decoded. I think the comments (which 
> pre-date your changes) also need to be re-examined as verifyFixClassname 
> as it will return JNI_FALSE when the scan is aborted.

Both functions abort similarly if UTF-8 sequences can't be decoded.
The fix- version just gets rid of logic to check for slashes, which is 
redundant at all existing call sites except the Class.forName one.

The fact we return JNI_FALSE when verifyFixClassname fails is a bit odd: 
this means we'll go into verifyClassname, fail the same way, and still
throw a CNFE, just with a slightly different message.


More information about the hotspot-runtime-dev mailing list