RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call

Bharadwaj Yadavalli bharadwaj.yadavalli at oracle.com
Wed Jan 9 07:44:49 PST 2013


David,

Thanks for looking at this.

As I noted in the mail in reply to Karen's review, it turns out that 
this fix for the three failures of Lambda tests does not have anything 
to do with the bug whose number is in the subject line - contrary to my 
initial impression that they are related. Hence, I have addressed them 
separately with separate code changes, tracked them with separate bug 
numbers and corresponding review requests. Sorry for the confusion.

Consequently, I sent out a code review request with subject : "RFR (S) - 
JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests" 
(http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-January/005125.html) 
to address the lambda test failures. The (new and improved) webrev is 
available at http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ as 
noted in that mail.

Thanks,

Bharadwaj

On 1/9/2013 5:18 AM, David Holmes wrote:
> The webrev for this seems to have vanished.
>
> But I would expect to only see a relaxation of the pre-8 rules to 
> accommodate default methods in 8. (The main one being interface method 
> => abstract)
>
> David
>
> On 4/01/2013 1:52 AM, Karen Kinnear wrote:
>> Bharadwaj,
>>
>> Thank you for sending this for review and for the fixes.
>>
>> A small note:
>> While I agree that the changes in the checking for the interface 
>> method modifiers matches the specification,
>> there are changes which are actually more restrictive than they used 
>> to be, so you want to back them out:
>>
>> 1. For<  jdk8 classfile, if is_protected or is_private is set - we 
>> used to ignore it. I'm sure javac enforces
>> that you can't have is_public as well as either is_protected or 
>> is_private, however for customers who
>> generate their own classfiles or for other static compilers, we don't 
>> want to throw a verifier error now
>> for classfiles that have worked in the past.
>>
>> 2. Same with is_bridge, is_varargs and is_synthetic - you don't want 
>> to check those for<  1.5
>>
>> Looks like we want some additional test cases for those for older 
>> classfile versions, as well
>> as test cases for classfile version 52 and is_synchronized and 
>> is_strict.
>>
>> Please also run the vm.quick.testlist tests and check if there are 
>> any other vmsqe tests that
>> are verifier/classfile parser specific.
>>
>> thanks,
>> Karen
>>


More information about the hotspot-runtime-dev mailing list