RFR: Lambda: 8009130 JCK lambda test fails with IllegalAccessException

[Lois Foltan]

On 10/3/2013 1:06 PM, Karen Kinnear wrote:
> Lois,
>
> How about base_class_search_defaults instead of 
> base_class_get_defaults? That would maybe
> remove some confusion?
Yes, I agree, base_class_search_defaults is better.  Thanks!
Lois

>
> thanks
> Karen
>
> On Oct 3, 2013, at 12:50 PM, Lois Foltan wrote:
>
>>
>> On 10/3/2013 12:47 PM, Karen Kinnear wrote:
>>> 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
>>
>> Hi Karen,
>> Yes, after I sent this yesterday a I realized my comment was a bit 
>> off given the name of the field itself
>> is "base_class_get_defaults".   I think you change is fine, thank you 
>> for the explanation.
>> Lois
>>
>>>
>>> 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/ 
>>>>> <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/20131003/252fef42/attachment.html