Truffle: Uncommon Traps in Graal graph code, TimSort

[Stefan Marr]

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

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525