Uncommon trap in OptimizedCallTarget::executeHelper

[Gilles Duboscq]

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?

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