Crash on current head + switchpoint patch

Mon Sep 5 22:50:32 PDT 2011

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.

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
>>> 
>> 
>> 