Truffle update instructions?

[Gilles Duboscq]

Hi Stefan,

On Wed, Apr 15, 2015 at 5:29 PM Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
>
> > On 15 Apr 2015, at 15:48, Andreas Woess <andreas.woess at oracle.com>
> wrote:
> >
> > The non-inlined calls to frame methods are definitely a performance
> issue. While I lifted the inlining cut off in a recent changeset, you still
> want to make sure these are inlined during partial evaluation, since (a)
> it's not guaranteed Graal will inline them and (b) they delay other
> optimizations. The reason appears to be once again the MaterializedFrame
> field in SBlock.context: in the new version of the partial evaluator, the
> type check needed to turn the interface call into an inlinable special call
> is inserted only after partial evaluation is finished. You can probably fix
> the problem (and the warning) by wrapping a type profile around the context
> frame (ValueProfile.createClassProfile()).
>
> Our best friend… Yes, I saw in the Sieve benchmark that closures got
> allocated where they shouldn’t after inlining.
>
> And indeed, the class profile helps. Thanks!
>
> There are still some regressions [1], like the FieldLoop, which measures
> field access performance, but I am currently more worried about compilation
> failures popping up.
>
> Andreas, did you just guess, or do you have a running version of
> TruffleSOM?
> I am asking, because it requires at least one patch to Graal currently.
>
> I am seeing Fannkuch and List failing. Locally, I see assertions in
> different phases of the PE failing.
>
> When Fannkuch is executed like this: ./graal.sh -cp
> Smalltalk:Examples/Benchmarks/LanguageFeatures
> Examples/Benchmarks/BenchmarkHarness.som Fannkuch  130 0 9
>
> VirtualUtil.assertNonReachable(.) fails in
> PEReadEliminationClosure.applyEffects, on line 104.
> The offending node is a ‘CommitAllocation’, and the allocation seems to
> refer to a som.interpreter.FrameOnStackMarker.
> A wild guess, could it be that the allocation is still needed elsewhere,
> for instance because the FrameOnStackMarker object escaped, which can
> happen as part of a ReturnException. The ReturnNonLocalNode, will read the
> marker from the outer lexical frame, to make sure the non-local return is
> legal.
>
> When List is executed like this: ./graal.sh -cp
> Smalltalk:Examples/Benchmarks/LanguageFeatures
> Examples/Benchmarks/BenchmarkHarness.som List 500 0 500
>
> The situation is different.
> The verification after canonicalization fails (after
> DominatorConditionalEliminationPhase).
> A GuardProxyNode has a value() of null.
>
> This verification seems bogus, currently null is ok as a value() for
GuardProxyNodes.


> I added another graph.verify() before the call to
> `canonicalizer.apply(.)`, that one doesn’t fail.
> So, it seems that there is something going on during canonicalization.
>
> Any ideas how I could dig deeper into this?
>

What happens if you just remove the value() != null assert in ProxyNode?


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