RFR: Lambda: 8009130 JCK lambda test fails with IllegalAccessException

[Lois Foltan]

Hi Karen,

Looks good, I like the clean up and I like the _default_methods list.  
I'm still grappling with understanding most of it, but I had one comment:

- runtime/reflectionUtils.hpp
    line #75 should the name of the member function be 
"base_class_set_defaults()"?

Thanks,
Lois

On 10/1/2013 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/6093097a/attachment.html