Virtual dispatch bug in 292 impl
Christian Thalinger
christian.thalinger at oracle.com
Fri Dec 21 12:30:22 PST 2012
On Dec 21, 2012, at 12:01 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
> On Dec 17, 2012, at 5:47 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
>>
>> On Dec 16, 2012, at 11:55 AM, Charles Oliver Nutter <headius at headius.com> wrote:
>>
>>> I wasn't sure if this had been filed already by Christian, so I wanted
>>> to post here.
>>>
>>> It appears that in C1, method handles are not properly dispatching to
>>> an overridden version of a method. My reproduction case is tied to
>>> JRuby, but I can come up with something isolated if necessary.
>
> I filed:
>
> https://jbs.oracle.com/bugs/browse/JDK-8005418
>
> But it seems to be C2, not C1:
>
> cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-client test_env.rb
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b69)
> Java HotSpot(TM) Client VM (build 25.0-b13, mixed mode)
>
> Run options:
>
> # Running tests:
>
> .
>
> Finished tests in 53.285000s, 0.0188 tests/s, 1876.7008 assertions/s.
>
> 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips
> cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:-TieredCompilation test_env.rb
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b69)
> Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode)
>
> Run options:
>
> # Running tests:
>
> F
>
> Finished tests in 2.222000s, 0.4500 tests/s, 424.8425 assertions/s.
>
> 1) Failure:
> test_bracket(TestEnv) [test_env.rb:11]:
> TypeError expected but nothing was raised.
>
> 1 tests, 944 assertions, 1 failures, 0 errors, 0 skips
> cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=3 test_env.rb
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b69)
> Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode)
>
> Run options:
>
> # Running tests:
>
> .
>
> Finished tests in 90.676000s, 0.0110 tests/s, 1102.8277 assertions/s.
>
> 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips
>
> -- Chris
>
>>>
>>> In JRuby, the ENV object is a subclass of a Ruby Hash. Rather than
>>> rebinding all of Hash's methods (defined on org.jruby.RubyHash), the
>>> ENV impl just overrides them at the Java level. When dispatching to
>>> the [] method on ENV with invokedynamic, the handle points at
>>> RubyHash.op_aref, the implementation of [] for Hash. The ENV version
>>> should raise an error...but it does not, because it dispatches to the
>>> superclass version rather than the subclass version.
What's the name of the [] implementation of ENV? Is it StringOnlyRubyHash.op_aref?
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)
@ 2 org.jruby.RubyHash::internalGet (9 bytes) inline (hot)
\-> TypeProfile (5247/5247 counts) = org/jruby/RubyHash
@ 2 org.jruby.RubyHash::internalGetEntry (51 bytes) inline (hot)
@ 1 java.lang.Object::hashCode (0 bytes) (intrinsic, virtual)
@ 4 org.jruby.RubyHash::hashValue (5 bytes) inline (hot)
@ 1 org.jruby.RubyHash::MRIHashValue (5 bytes) inline (hot)
@ 18 org.jruby.RubyHash::bucketIndex (6 bytes) inline (hot)
@ 2 org.jruby.RubyHash::MRIBucketIndex (7 bytes) inline (hot)
@ 31 org.jruby.RubyHash::internalKeyExist (42 bytes) inline (hot)
@ 1 org.jruby.RubyHash$RubyHashEntry::access$300 (5 bytes) inline (hot)
@ 9 org.jruby.RubyHash$RubyHashEntry::access$500 (5 bytes) inline (hot)
@ 40 org.jruby.RubyHash$RubyHashEntry::access$200 (5 bytes) inline (hot)
@ 5 org.jruby.RubyHash$RubyHashEntry::access$400 (5 bytes) inline (hot)
-- Chris
>>>
>>> If I turn off tiered compilation, the code works as expected.
>>>
>>> Reproduction for JRuby is here: https://gist.github.com/4311979
>>>
>>> I tested on hotspot-comp built yesterday:
>>>
>>> openjdk version "1.8.0-internal"
>>> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2012_12_15_16_45-b00)
>>> OpenJDK 64-Bit Server VM (build 25.0-b13, mixed mode)
>>>
>>> If I have time I'll try to investigate in more depth.
>>
>> This is really odd. I've fixed a similar bug some time ago:
>>
>> https://jbs.oracle.com/bugs/browse/JDK-8000821
>> http://bugs.sun.com/view_bug.do?bug_id=8000821
>>
>> And there is currently a bug with Nashorn that sounds like the same issue.
>>
>> Is it intermittent? Are you able to reproduce with TieredStopAtLevel=1?
>>
>> -- Chris
>>
>>>
>>> - Charlie
>>
>
More information about the hotspot-compiler-dev
mailing list