Truffle: Uncommon Traps in Graal graph code, TimSort

[Andreas Woess]

Hi Stefan,

the uncommon traps are expected behavior and the result of optimistic
optimizations, here in the Graal compiler itself.

I'm not familiar with your code base, but I suspect that you don't
report loop counts in your while loop implementation. The main trigger
for compilation is the compilation threshold, which is currently set to
1000 (see the TruffleCompilerOptions class for more options). Methods
that have long-running loops and don't report their loop counts are only
compiled if the method that contains the loop itself is called >1000 times.
See the following exemplary implementation of a while loop for how you
can report loop iteration counts:

WhileNode::execute(VirtualFrame frame) {
    int count = 0;
    try {
        while (executeCondition(frame)) {
            executeBody(frame);
            if (CompilerDirectives.inInterpreter()) {
                count++;
            }
        }
    } finally {
        if (CompilerDirectives.inInterpreter()) {
            reportLoopCount(count);
        }
    }
}

and the reportLoopCount method would be:

private void reportLoopCount(int count) {
    CompilerAsserts.neverPartOfCompilation();
    RootNode rootNode = this.getRootNode();
     if (rootNode != null && rootNode.getCallTarget() instanceof
LoopCountReceiver) {
        ((LoopCountReceiver)
rootNode.getCallTarget()).reportLoopCount(count);
    }
}

This should help methods with long loops be compiled earlier (and also
quicken inlining). Let me know if this helps.

Regarding the previous email thread, let's try, as Chris suggested, to
optimize a simple benchmark like fannkuch (which we know performs well
in other Truffle languages). We can provide some assistance after the
holidays.

Happy new year,
- Andreas

On 30.12.2013 18:41, Stefan Marr wrote:
> Hi:
>
> I’ll report later on all the changes in TruffleSOM. So just briefly: it is slowly getting faster.
>
> My actual question is related to strange behavior I am seeing.
>
> On benchmarks like DeltaBlue, Richards, and also:
> ./mx.sh --vm server vm -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 FieldLoop 10 10 6000
>
> [Please note in the command line, I adopted the truffle.jar, which changes the line slightly compared to previous examples posted.]
>
> I see a lot of:
>
> Uncommon trap occurred in com.oracle.graal.nodes.MergeNode$1::apply
> Uncommon trap occurred in com.oracle.graal.graph.iterators.NodePredicates$AndPredicate::apply
> Uncommon trap occurred in com.oracle.graal.virtual.phases.ea.PartialEscapeClosure$MergeProcessor::mergeObjectStates
> Uncommon trap occurred in com.oracle.graal.lir.LIRIntrospection::forEach
> Uncommon trap occurred in java.util.TimSort::sort
>
> and similar traps.
>
> This looks strange to me. Is this supposed to happen?
>
> One thing I feel might be the issue is that the benchmarks cause many recompilations because of long phases of specialization. From my subjective feeling, the inlining in TruffleSOM is rather slow, i.e., happens rather later. And it proper gates up the call tree which leads to many re-inlining/re-specialization of in the middle and at the bottom of the tree. So, reaching steady state takes pretty long. And I am talking here about many many iterations before it stabilizes, which results in long warmup times rather on the side of minutes than seconds. Something as simple as the WhileLoop benchmarks takes 30s.
>
> So, that’s perhaps unrelated to the original question of whether those uncommon traps in Graal code should happen. For the warmup, could it be that Smalltalk’s  ‘make a method not longer than 7 lines’ could require different thresholds for inlining etc.?
>
> Thanks and best regards
> Stefan
>