Crash on current head + switchpoint patch (original) (raw)

Tom Rodriguez tom.rodriguez at oracle.com
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 invokecount 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(invokecount != 0, "require invocation count greater than zero"); - int freq = callsitecount / invokecount; + int freq = invokecount > 0 ? (callsitecount / invokecount) : 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 ./redblacktree.rb:68:in method_11$RUBY$initialize'_ _from <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>d</mi><mi>o</mi><mi>t</mi></mrow><annotation encoding="application/x-tex">dot</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.6944em;"></span><span class="mord mathnormal">d</span><span class="mord mathnormal">o</span><span class="mord mathnormal">t</span></span></span></span>redblacktree$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$rbtbm' from bm1$method_0$RUBY$rbtbm:65535:in call'_ _from bm1$method_0$RUBY$rbtbm:65535:in call' from MethodHandle.java:566:in invokeWithArguments'_ _from InvokeDynamicSupport.java:464:in invocationFallback' from bm1.rb:30:in block10$RUBY$_file_'_ _from bm1$block10$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 invokeL5'_ _from MethodHandleImpl.java:1154:in invokeL5' 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$ JAVAHOME=../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.002-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::shouldinline(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/hserrpid14498.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