Optimizing Method Lookup in Truffle

[Chris Seaton]

Sorry, then you also need to override toString in method.

Eg https://github.com/smarr/TruffleSOM/pull/1


On 9 September 2013 11:30, Chris Seaton <chris at chrisseaton.com> wrote:

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