Optimizing Method Lookup in Truffle

[Stefan Marr]

Hi Thomas:

On 10 Aug 2013, at 12:53, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:

> Stefan,
> 
> One of the first steps towards speeding up the implementation is to cache information in the nodes that are useful for subsequent execution. The first candidate for this would be caching the receiverClass and the looked up Invokable instance in the MessageNode class. For this, you need two types of guards:

Thanks for the hints. I finally got around to implement specialize MessageNodes that do inline caching [1].
I experimented with a simple monomophic cache and a polymorphic one.

However, I have encountered a few difficulties along the way, and it is not yet working perfectly.

The first thing I tried was to represent the check for whether the receiver's class is the cached one as an Assumption.
Unfortunately, I ran into complains from the Graal stack that certain code paths were compiled which should not have been.
So, I changed it to something that seems to be close to the advice you gave to Mark:

if (currentRcvrClass == rcvrClass) { // cache hit
  return invokable.invoke(frame.pack(), rcvr, args);
} else { // not a monomorpic send site
  CompilerDirectives.transferToInterpreter();
  PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver,
    arguments, selector, universe, rcvrClass, invokable, currentRcvrClass);
  this.replace(poly, "It is not a monomorpic send.");
  return doFullSend(frame, rcvr, args, currentRcvrClass);
}

A check of whether the invokable hasn't changed isn't included yet, because I got trouble again with invalidation of methods.

First, I had issues with @Child/@Children annotations missing on the tree node fields, and adoptChild not being used consistently, but I figured that out.
Would be great if Truffle could warn about such issues. I guess, a field in a Node subclass that is of the type of a Node is most likely to be a @Child, and it should most likely be assigned with the return value of adoptChild(.) instead of being assigned directly with the parameter. Since I got that wrong, some replace operations did not succeed completely, and I had uninitialized nodes executing more than once, which was unexpected.

After fixing such issues, I now have a working version, but the Queens and Bounce benchmarks run very slowly because some method gets constantly recompiled.
The output produced by the following command line is not exactly enlightening.

./mx.sh --vm server vm -XX:+TraceDeoptimization -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som

Is there a way to obtain the name of the Method with a given id? Or correlate it with what could be the most likely cause?
While you have been debugging these issues earlier for me, it would be great if you could give me some hints on how to debug them myself.
What's the approach you would take to figure out the reasons for these invalidations?

Thanks a lot
Stefan


[1] https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf 


-- 
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