Truffle update instructions?

[Stefan Marr]

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.

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?

Thanks
Stefan

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