RFR: Lambda: 8009130 JCK lambda test fails with IllegalAccessException

[Karen Kinnear]

Lois,

This was one of the more complex things I changed. Actually, the name of the boolean is base_class_get_defaults, i.e.
should the base class perform get_defaults (the streaming is a bit interesting, for method walks we want to walk 
default methods, but only once, so I needed to set a boolean so that the state could be read by the other players.

If you think of a better name, I'm all ears.

thanks,
Karen

p.s. we don't use the terms "get" and "set" in getters and setters - but I hear you  - this looks like I am doing just that

On Oct 2, 2013, at 1:21 PM, Lois Foltan wrote:

> 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/
>> 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/20131003/e75b3e29/attachment.html