RFR: 8230043: Lazily load libverify

[Claes Redestad]

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.

/Claes