Uncommon trap in OptimizedCallTarget::executeHelper

[Andreas Woess]

Hi again,

I've committed a fix that should solve this issue. It will arrive in the
openjdk repository by tomorrow. I also suggest you add @SlowPath to
Universe.{get,set,has}Global.

- andreas

On 20.01.2014 19:26, Andreas Woess wrote:
> 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/
>>>>
>>>>
>>>>
>