RFR: Lambda: 8009130 JCK lambda test fails with IllegalAccessException

[yumin.qi at oracle.com]

  I guess the correct URL is:

http://cr.openjdk.java.net/~acorn/8009130.3/webrev/ 
<http://cr.openjdk.java.net/%7Eacorn/8009130.3/webrev/>

I am in reviewing and will update you soon.

Thanks
Yumin

On 10/2/2013 10:24 AM, Karen Kinnear wrote:
> I updated the webrev - just the defaultMethods.cpp. This failed a jck 
> resolveMethod00705m2 test
> so I am negotiating a minor specification correction which I think is 
> the behavior we want and
> matches the updated code (and creates an AME for the result of default 
> method resolution as
> Keith did originally if the resultant method is abstract).
>
> http://cr.openjdk.java.net/~acorn/8009103.3/webrev/ 
> <http://cr.openjdk.java.net/%7Eacorn/8009103.3/webrev/>
>
> thanks,
> Karen
>
>
>
> On Oct 1, 2013, at 10:01 PM, Karen Kinnear wrote:
>
>>
>> Please review: JCK lambda test fails with IllegalAccessException
>> Also fixes: 8013085: Default method bridges have incorrect class 
>> loading constraints
>> 8025288: Two JCK runtime tests failed with IllegalAccessError
>>
>> webrev: http://cr.openjdk.java.net/~acorn/8009130.2/webrev/ 
>> <http://cr.openjdk.java.net/%7Eacorn/8009130.2/webrev/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8009130
>>
>> Summary:
>> See bug report for further details.
>>
>> After several prototypes, current approach is to simplify how default 
>> methods are handled by:
>> 1) not using overpasses (vm generated bridges) for invoking default 
>> methods, not using a second
>> step invokespecial
>>    - this removes the problem with invokespecial's constant pool 
>> lookup that requires class access
>>     (of the original invocation's "selected" method)
>> 2) creating default_methods_array in the inheriting instanceKlass 
>> with public default methods (and default_vtable_indices)
>> 3) search order for method and interface method resolution (to match 
>> the 0.6.3+ JVMS spec update):
>>    local class methods, super class methods, default methods, 
>> transitive interfaces
>> 4) adding the default method to the vtable directly, with the default 
>> method having the correct
>>    method holder, which allows the access permission and loader 
>> constraint tests run on
>>    the resolved method to work on the correct method holder/class loader
>> 5) overpasses are still used for errors detected during default 
>> method processing, such
>>   as ICCE for conflicts with default methods, and abstract method 
>> error for no candidate methods found,
>>   these are still added to the inheriting method's local method array 
>> and constant pool at this time
>>
>> My goal is to check this in by the end of the week for next Tuesday's 
>> hotspot-rt deadline.
>>
>> thanks,
>> Karen
>>
>> Tests run: (64 bit linux)
>> 1. 8009130 reported bug
>> 2. 8009103 jck tests:
>>     lang/INTF/intf024/intf02402m01/intf02402m01.html
>>    lang/INTF/intf024/intf02402m11/intf02402m11.html
>>    lang/CLSS/clss475/clss47501m21/clss47501m21
>>    lang/CLSS/clss475/clss47501m211/clss47501m211
>> 3. 8013085: Loader Constraint example
>> 4. default methods tests
>> 5. intfbug
>> 6. jtreg jdk: filteroptest
>> 7. reflection modeling tests (Reflect2, ReflectInvokeprivatesmall)
>> 8. jcmd <pid> GC.class_stats
>> -- tests which ran prior to latest hotspot-rt merge and will rerun in 
>> parallel with code review
>> 9. vm.quick.testlist
>> 10. vm.mlvm.testlist
>> 11. jtreg jdk java.util, java.lang
>> 12. jck vm
>> 13. jck lang
>> 14. nsk.hprof.testlist
>> 15. nsk.quick-jvmti.testlist
>> 16. jck api/java_util/TreeSet/ParallelStream.html
>> 17. jprt -stree .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131002/cf4004d5/attachment.html