Virtual dispatch bug in 292 impl

[Christian Thalinger]

On Jan 7, 2013, at 4:42 PM, Charles Oliver Nutter <headius at headius.com> wrote:

> A quick test of the fix Christian gave me seems to indicate that
> things are working. Yay!

Thanks for verifying.

> 
> Will try running our comprehensive "all" suite this evening.

Please also look out for performance regressions.  I've found at least one with Nashorn.

-- Chris

> 
> - Charlie
> 
> On Thu, Jan 3, 2013 at 2:24 PM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> Sorry I lost track of this thread going into the holidays...I talked
>> to Christian a moment ago but I reply here for the record...
>> 
>> Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> I filed:
>>>> 
>>>> https://jbs.oracle.com/bugs/browse/JDK-8005418
>>>> 
>>>> But it seems to be C2, not C1:
>> 
>> Does look that way in your output. I'll leave it in your hands. I will
>> say I am almost positive that when I ran with tier=1 it failed, and
>> -tiered worked ok, but I don't have the output in front of me.
>> 
>>> What's the name of the [] implementation of ENV?  Is it StringOnlyRubyHash.op_aref?
>> 
>> Yes, that's the one. The handle points at the superclass impl,
>> RubyHash.op_aref, and that's the one that gets hit instead of the
>> override.
>> 
>>> Could this be the compile that goes wrong?
>>> 
>>>  12903  956             java.lang.invoke.LambdaForm$MH/847376::convert (52 bytes)
>>>                            @ 15   java.lang.invoke.LambdaForm$BMH/23638730::reinvoke (26 bytes)   inline (hot)
>>>                              @ 12   java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 bytes)   inline (hot)
>>>                              @ 22   java.lang.invoke.LambdaForm$DMH/20340225::invokeStatic_LL_L (15 bytes)   inline (hot)
>>>                                @ 1   java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)   inline (hot)
>>>                                @ 11   sun.invoke.util.ValueConversions::castReference (6 bytes)   inline (hot)
>>>                                  @ 2   java.lang.Class::cast (27 bytes)   inline (hot)
>>>                                    @ 6   java.lang.Class::isInstance (0 bytes)   (intrinsic)
>>>                            @ 33   java.lang.Class::cast (27 bytes)   inline (hot)
>>>                              @ 6   java.lang.Class::isInstance (0 bytes)   (intrinsic)
>>>                            @ 43   java.lang.Class::cast (27 bytes)   inline (hot)
>>>                              @ 6   java.lang.Class::isInstance (0 bytes)   (intrinsic)
>>>                            @ 48   java.lang.invoke.LambdaForm$DMH/32367447::invokeVirtual_LLL_L (18 bytes)   inline (hot)
>>>                              @ 1   java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)   inline (hot)
>>>                              @ 14   org.jruby.RubyHash::op_aref (23 bytes)   inline (hot)
>> 
>> This looks like what I saw while debugging, yes. Not sure if this
>> exact output is right because there's not much context, but I did see
>> the call that *should* have been going to StringOnlyRubyHash.op_aref
>> going to RubyHash.op_aref.
>> 
>> There aren't many such cases in JRuby...most overrides are accompanied
>> by an override in the Ruby class structures, so the child class has
>> its own handle pointing at the override. That's probably why we don't
>> see it in more places.
>> 
>> I have not retested with any of the recent work on partial inlining,
>> etc. Since it looks like you're able to reproduce it ok, I'll leave it
>> in your hands. Let me know what else I can do.
>> 
>> - Charlie