Optimizing Method Lookup in Truffle

[Chris Seaton]

It doesn't look like you assignSourceSection to your RootNode (Method
class) anywhere. I think Truffle uses that source section to give a name to
methods when in the trace outputs, so if you do that you may get the info
you want.

Chris


On 8 September 2013 23:20, Stefan Marr <java at stefan-marr.de> wrote:

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