Uncommon trap in OptimizedCallTarget::executeHelper

[Andreas Woess]

Hi Stefan,

I've looked into the graph of the invalidated method. There appears to
be a bug in the truffle compiler regarding non-local returns. Thanks for
the report. We'll fix it.

- andreas

On 20.01.2014 15:21, Stefan Marr wrote:
> On 20 Jan 2014, at 15:08, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
>
>> I just checked out the som repository (and its core-lib submodule) and
>> still didn't get a truffle invalidation with the WhileLoopVAt
>> benchmark.
>> Can you give the exact steps to reproduce (maybe including git/hg
>> version) so that we are sure we are talking about the same thing?
> Indeed, sorry, I am a bit distracted today.
>
> I added a work around, but to stay with this simple example, here the original version of Vector.som in the Smalltalk directory (or core-lib/Smalltalk on Windows).
>
>
>
>
> To produce a reasonable amount of output only I also changed the loop iteration counts and benchmark iteration counts.
> On the command-line, all the numbers at the end are set to 1. And, the loop bounds changed to 600 and 20 (see code below)
>
> I am now starring at the graph you pointed me at.
> And from what I see, it looks a bit like a polymorphic inline cache check is failing and resulting in the ‘unreached code’ guard being triggered. What I don’t understand is why it is happening again and again.
>
>
>
> ./mx.sh --vm server vm  -G:Dump= -XX:+TraceDeoptimization -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/Richards ../som/Examples/Benchmarks/BenchmarkHarness.som WhileLoopVAt 1 1 1
>
>
>
> WhileLoopVAt = Benchmark (
>
>     singleRun = (
>         | sum v |
>         v := Vector new.
>         v at: 1 put: 1.
>         sum := 0.
>         [sum < 600]
>             whileTrue:
>                 [sum := sum + (v at: 1)].
>         ^ sum
>     )
>
>     benchmark = ( 
>         | sum |
>         sum := 0.
>         [sum < 20]
>             whileTrue:
>                 [sum := sum + self singleRun].
>         ^ sum
>     )
> )
>
>> Regarding this 'null_assert|unreached0', i admit it's a bit confusing
>> but we somehow "misuse" a deoptimization reason from hotspot which is
>> why we have this strange name. For Graal this really means just
>> "unreached" which normally means the code reached a branch that was
>> never taken before however in the context of Truffle, we don't use the
>> bytecode profile so the causes can be:
>> - a UnexpectedResultException or a RuntimeException which is not a
>> ControlFlowException has been thrown (in which case the 'action' is
>> 'reinterpret', like in your example)
>> - CompilerDirectives.transferToInterpreter has been called (but then
>> the 'action' would be 'none')
>> - CompilerDirectives.transferToInterpreterAndInvalidate has been
>> called (in which case the 'action' is 'reinterpret', like in your
>> example)
>>
>> -Gilles
>>
>> On Mon, Jan 20, 2014 at 1:19 PM, Stefan Marr <java at stefan-marr.de> wrote:
>>> Hi Gilles:
>>>
>>> On 20 Jan 2014, at 13:05, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
>>>
>>>> I checked som out (e8856e995185720bd2b7b50e8efe09a5b04d7be1) and i
>>>> tried to run your example. I couldn't find WhileLoopVAt so i ran
>>>> WhileLoop:
>>> Sorry, I forgot to push to the right repository. It’s now there.
>>>
>>>> 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.
>>> Ok, will try to have a look and see whether that helps me further.
>>> Thanks for the explanation.
>>>
>>> Best regards
>>> Stefan
>>>
>>> --
>>> Stefan Marr
>>> INRIA Lille - Nord Europe
>>> http://stefan-marr.de/research/
>>>
>>>
>>>