Uncommon trap in OptimizedCallTarget::executeHelper

[Stefan Marr]

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).

-------------- next part --------------


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

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/