RFR: Lambda: 8009130 JCK lambda test fails with IllegalAccessException

[Karen Kinnear]

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/

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/
> 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/afae984b/attachment-0001.html