Crash on current head + switchpoint patch

Tom Rodriguez tom.rodriguez at oracle.com
Tue Sep 6 08:39:59 PDT 2011 

On Sep 6, 2011, at 1:40 AM, Christian Thalinger wrote:

> 
> On Sep 6, 2011, at 7:50 AM, Tom Rodriguez wrote:
> 
>> The fix for 7071307 seems to have made it disappear, though I'm not sure why.  It may just perturb the inlining such that it doesn't occur in this case.  I think it's still a potential problem or at least it needs to be confirmed that it isn't a problem.
> 
> I think it's not a problem.  The caller is a method handle adapter and so is the callee:
> 
> (dbx) p caller_method->is_method_handle_adapter()
> caller_method->is_method_handle_adapter() = true
> (dbx) p callee_method->is_method_handle_adapter() 
> callee_method->is_method_handle_adapter() = true
> 
> The logic in InlineTree::should_inline tests for caller_method->is_method_handle_adapter() and since the MDO data returns zero as invoke_count we hit the assert.  But 7071307 adds this check:
> 
> +     if (invoke_count == 0) {
> +       return "method handle not reached";
> +     }

Sounds good. Thanks for figuring this out.

tom

> 
> resulting in:
> 
>                            @ 200   java.lang.invoke.MethodHandle::invokeExact (41 bytes)   inline (hot)
>                              @ 8   java.lang.invoke.MethodHandle::invokeExact (20 bytes)   method handle not reached
>                              @ 17   java.lang.invoke.MethodHandle::invokeExact (12 bytes)   method handle not reached
> 
> I think we are good and can close 7086187 as a duplicate of 7071307.
> 
> -- Christian
> 
>> 
>> tom
>> 
>> On Sep 5, 2011, at 4:02 PM, Charles Oliver Nutter wrote:
>> 
>>> The same case that blew up before doesn't blow up now with
>>> hotspot-comp tip. Not sure if it's a heisenbug or if other changes
>>> made the >0 check unnecessary.
>>> 
>>> - Charlie
>>> 
>>> On Mon, Sep 5, 2011 at 8:31 AM, Christian Thalinger
>>> <christian.thalinger at oracle.com> wrote:
>>>> I'm not able to reproduce it.  What JRuby GIT revision fails?
>>>> 
>>>> -- Christian
>>>> 
>>>> On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote:
>>>> 
>>>>> I reproduced it.  Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0.  When we try to use that zero as a scale for inlining tests of callees we get a div by zero.  The problem has always been there I think but it was masked by the inline size cutoffs.  We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles.  I filed 7086187 for this.  If you need a workaround, this should work.
>>>>> 
>>>>> diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp
>>>>> --- a/src/share/vm/opto/bytecodeInfo.cpp
>>>>> +++ b/src/share/vm/opto/bytecodeInfo.cpp
>>>>> @@ -145,7 +145,7 @@
>>>>> }
>>>>> 
>>>>> assert(invoke_count != 0, "require invocation count greater than zero");
>>>>> -  int freq = call_site_count / invoke_count;
>>>>> +  int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0;
>>>>> 
>>>>> // bump the max size if the call is frequent
>>>>> if ((freq >= InlineFrequencyRatio) ||
>>>>> 
>>>>> You'd need to disable the assert too if you wanted to run fastdebug.
>>>>> 
>>>>> By the way, after working around it, I get this:
>>>>> 
>>>>> dbx) c
>>>>> MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject
>>>>>      from MethodHandles.java:2166:in `misMatchedTypes'
>>>>>      from MethodHandles.java:2150:in `guardWithTest'
>>>>>      from SwitchPoint.java:173:in `guardWithTest'
>>>>>      from InvokeDynamicSupport.java:660:in `updateInvocationTarget'
>>>>>      from InvokeDynamicSupport.java:462:in `invocationFallback'
>>>>>      from ./red_black_tree.rb:68:in `method__11$RUBY$initialize'
>>>>>      from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call'
>>>>>      from CachingCallSite.java:142:in `callBlock'
>>>>>      from CachingCallSite.java:148:in `call'
>>>>>      from RubyClass.java:798:in `newInstance'
>>>>>      from RubyClass$i$newInstance.gen:65535:in `call'
>>>>>      from JavaMethod.java:256:in `call'
>>>>>      from MethodHandle.java:566:in `invokeWithArguments'
>>>>>      from InvokeDynamicSupport.java:464:in `invocationFallback'
>>>>>      from bm1.rb:16:in `method__0$RUBY$rbt_bm'
>>>>>      from bm1$method__0$RUBY$rbt_bm:65535:in `call'
>>>>>      from bm1$method__0$RUBY$rbt_bm:65535:in `call'
>>>>>      from MethodHandle.java:566:in `invokeWithArguments'
>>>>>      from InvokeDynamicSupport.java:464:in `invocationFallback'
>>>>>      from bm1.rb:30:in `block_10$RUBY$__file__'
>>>>>      from bm1$block_10$RUBY$__file__:65535:in `call'
>>>>>      from CompiledBlock.java:112:in `yield'
>>>>>      from CompiledBlock.java:95:in `yield'
>>>>>      from Block.java:130:in `yield'
>>>>>      from RubyFixnum.java:252:in `times'
>>>>>      from MethodHandleImpl.java:1154:in `invoke_L5'
>>>>>      from MethodHandleImpl.java:1154:in `invoke_L5'
>>>>>      from MethodHandle.java:566:in `invokeWithArguments'
>>>>>      from InvokeDynamicSupport.java:538:in `invocationFallback'
>>>>>      from bm1.rb:29:in `__file__'
>>>>>      from bm1.rb:-1:in `load'
>>>>>      from Ruby.java:715:in `runScript'
>>>>>      from Ruby.java:708:in `runScript'
>>>>>      from Ruby.java:615:in `runNormally'
>>>>>      from Ruby.java:464:in `runFromMain'
>>>>>      from Main.java:317:in `doRunFromMain'
>>>>>      from Main.java:237:in `internalRun'
>>>>>      from Main.java:203:in `run'
>>>>>      from Main.java:187:in `run'
>>>>>      from Main.java:167:in `main'
>>>>> 
>>>>> Anyway, thanks for the report.
>>>>> 
>>>>> tom
>>>>> 
>>>>> On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote:
>>>>> 
>>>>>> I'm running a build of hotspot-comp from today plus Christian's
>>>>>> "switchpoint push invalidation" patch. Getting the following crash
>>>>>> running the "redblack" benchmark (http://github.com/headius/redblack):
>>>>>> 
>>>>>> headius at headius-vbox-ubuntu:~/projects/redblack$
>>>>>> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby
>>>>>> -Xinvokedynamic.all=true -X+C bm1.rb 20
>>>>>> #
>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>> #
>>>>>> #  SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032
>>>>>> #
>>>>>> # JRE version: 7.0_02-b05
>>>>>> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode
>>>>>> linux-amd64 compressed oops)
>>>>>> # Problematic frame:
>>>>>> # V  [libjvm.so+0x2719c0]  InlineTree::should_inline(ciMethod*,
>>>>>> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100
>>>>>> #
>>>>>> # Failed to write core dump. Core dumps have been disabled. To enable
>>>>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>>>>> #
>>>>>> # An error report file with more information is saved as:
>>>>>> # /home/headius/projects/redblack/hs_err_pid14498.log
>>>>>> #
>>>>>> # If you would like to submit a bug report, please visit:
>>>>>> #   http://bugreport.sun.com/bugreport/crash.jsp
>>>>>> #
>>>>>> Aborted
>>>>>> 
>>>>>> Should be easy to produce, but I can provide any info you need. JRuby
>>>>>> master, amd64 product build. -Xinvokedynamic.all is the same as
>>>>>> -Djruby.invokedynamic.all and turns on all current uses of
>>>>>> invokedynamic (some are off because they're slow in Java 7 GA).
>>>>>> 
>>>>>> - Charlie
>>>>> 
>>>> 
>>>> 
>> 
>

More information about the hotspot-compiler-dev mailing list