Crash on current head + switchpoint patch

Rémi Forax forax at univ-mlv.fr
Thu Sep 1 18:11:34 PDT 2011


On 09/02/2011 02: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'

oups, Charles, you forget to bind the callsite :)

>
> Anyway, thanks for the report.
>
> tom

Rémi



More information about the hotspot-compiler-dev mailing list