Uncommon trap in OptimizedCallTarget::executeHelper

[Gilles Duboscq]

Hi Stefan,

I checked som out (e8856e995185720bd2b7b50e8efe09a5b04d7be1) and i
tried to run your example. I couldn't find WhileLoopVAt so i ran
WhileLoop:

  mx --vm server vm -G:+TraceTruffleExpansion
-G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization
-G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails
-Xbootclasspath/a:../../som/build/classes:../../som/libs/truffle.jar
som.vm.Universe -cp ../../som/Smalltalk
../../som/Examples/Benchmarks/BenchmarkHarness.som WhileLoop 20 10
1000

but i didn't get any uncommon trap in the Truffle compiled code (and
so no "[truffle] invalidated Method..."). Can you share the code of
WhileLoopVAt so that i can reproduce the problem?
When you see deoptimization, the bci you see is only the bci where
execution will be restarted which is usually some point before the
actual source of the deoptimization.
To debug these kind of things, i would dump the compilation graph to
the IGV, doing so will give you some data in the "debug_id" (a recent
rename, it was "speculation" in your traces) this will be the id of
the Guard which failed. I then go to the graph just before the
GuardLoweringPhase and look for this guard from there on, it's
possible to track where this guard comes from.

-Gilles

On Fri, Jan 17, 2014 at 5:33 PM, Stefan Marr <java at stefan-marr.de> wrote:
> Hi:
>
> On 17 Jan 2014, at 13:12, Stefan Marr <java at stefan-marr.de> wrote:
>
>> """
>> Uncommon trap   bci=0 pc=39901936, relative_pc=144, method=executeHelper, speculation=0
>> <uncommon_trap thread='6403' reason='null_assert|unreached0' action='reinterpret' speculation='0' compile_id='-1' compiler='Graal' level='1' count='141' state='null_assert|unreached0 recompiled' recompiles2='140' stamp='8.999'>
>> Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod&lt;OptimizedCallTarget.executeHelper(PackedFrame, Arguments)&gt;)  (@0x000000010260daf0) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0
>> <jvms bci='0' method='com/oracle/graal/truffle/OptimizedCallTarget executeHelper (Lcom/oracle/truffle/api/frame/PackedFrame;Lcom/oracle/truffle/api/Arguments;)Ljava/lang/Object;' bytes='19' count='8139' iicount='8139' throwouts='391' decompiles='141' null_assert|unreached0_traps='141' overflow_recompiles='140'/>
>> </uncommon_trap>
>> “""
>
> So, these “null_assert|unreached0” traps are haunting me.
> I chased now a couple of issues, which all dead-ended in something similar to this:
>
> Uncommon trap   bci=14 pc=285007556, relative_pc=6596, method=invoke, speculation=0
> <uncommon_trap thread='6403' reason='null_assert|unreached0' action='reinterpret' speculation='0' compile_id='-1' compiler='Graal' level='1' count='119' state='null_assert|unreached0 recompiled' recompiles2='118' stamp='19.855'>
> Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod&lt;OptimizedCallTarget.executeHelper(PackedFrame, Arguments)&gt;)  (@0x0000000110fcdec4) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0
> <jvms bci='14' method='som/vmobjects/SMethod invoke (Lcom/oracle/truffle/api/frame/PackedFrame;Ljava/lang/Object;Ljava/lang/Object;Lsom/vm/Universe;)Ljava/lang/Object;' bytes='18' count='3493' iicount='3493' throwouts='133'/>
> <jvms bci=’16' method='som/primitives/BlockPrims$ValueOnePrim doSBlock (Lcom/oracle/truffle/api/frame/VirtualFrame;Lsom/vmobjects/SBlock;Ljava/lang/Object;)Ljava/lang/Object;' bytes='20' count='3493' iicount='3493' throwouts='133'/>
>
> In this particular case, we are talking about a method that looked like this:
>
> public Object invoke(final PackedFrame caller, final Object self, final Object arg, final Universe universe) {
>   return callTarget.call(caller, new BinaryArguments(self, arg));
> }
>
> No idea what’s going on here. And if I can trust the Eclipse Bytecode Outliner, then there is also no bytecode index of 14.
>
> What is the exact meaning of that trap?
> I guess something like: one branch of a null assertion was reached, that wasn’t compiled?
>
>
> Thanks
> Stefan
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>