RFR: 8230043: Lazily load libverify
claes.redestad at oracle.com
Sun Aug 25 19:35:52 UTC 2019
On 2019-08-24 10:00, Alan Bateman wrote:
> On 23/08/2019 14:08, Claes Redestad wrote:
>> please review this cleanup to untangle the old bytecode verifier
>> (libverify). It's currently linked and loaded eagerly and early during
>> 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 core-libs-dev