Truffle CallNode API

[Christian Humer]

Hi Stefan,

Sorry for not giving you a pre-notice on that change. Should have done that.
I've attached a small patch (off list) for the BinarySend on how I think
you can try to align your interpreter to the new CallNode. (I've not run
the patch, nor does it compile, nor did I change the other send types, so
no guarantees ;-) )

CallNode is supposed to be used as a child node in your inline cache
whenever a CallTarget is considered constant. So it is not considered to be
subclassed (and that is an important part of the concept). If you
(CallNode#inline) or the heuristic decides to inline a node it now
internally copies to RootNode with RootNode#inline and then calls the
RootNode instead of the CallTarget. Yes you are right, this introduces some
more nodes to your AST, which you could previously get rid of by replacing
the complete inline cache entry with the inlined version of the function.
However Truffle/Graal is smart enough to still have the same performance in
the compiled version of the function (the allocation of the arguments
object and boxing goes away).

The node is there to hand a certain kind of control over calls to the
Truffle Framework. On the long term I want to realize not just inlining but
also things like tail recursion optimization on a Truffle level with that
node.

I wanted to support inlining without the need of implementing the
interfaces InlinableCallNode and InlinedCallSite. Which resulted in
implementing the same interpreter profiling (callcount) for inlining
separately for every guest language. This means if there was a change to
the inlining heuristic that required additional profiling we had to add
that in all the guest languages that do inlining. With the CallNode I can
now define the interpreter profiling myself that is required for the
heuristic. The guest language implementor does not have to worry about that
anymore. (he can still tune the parameters)

I also wanted to hide inlining mostly from the guest language implementor.
So inlining should be an additional optimization that truffle performs but
it should have no effect on the public tree structure. In that way the
guest language implementor does not need to worry if he is in an inlined
node or not by default. However if he wants to he can use
RootNode#getParentInlinedCall() as well as CallNode#getInlinedRoot() to
access the inlined trees as well. But that is usually the exception (I
think).

Please feel free to ask further questions.

- Christian Humer


On Thu, Jan 30, 2014 at 9:53 PM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Christian:
>
> On 29 Jan 2014, at 22:09, Christian Humer <christian.humer at gmail.com>
> wrote:
>
> > I just updated the Truffle Inlining API with a more robust solution (will
> > get pushed to openjdk this night).
> > I removed the old API namely the following interfaces InlinableCallSite
> and
> > InlinedCallSite.
> > As a replacement for those classes you should now use a new class
> CallNode.
> > This class is already a Node and can directly be used as such inside of
> an
> > polymorphic function inline cache.
> > For further information on how to use it please see SLDirectDispatchNode
> > and the javadoc in the CallNode class.
>
> I still haven't looked for an alternative solution to my explicit
> Unary/Binary/Ternary/Keyword nodes, which facilitate specialization of
> things like add. But this change seems to be incompatible with my solution,
> because I am not really supposed to subclass CallNode, right? At least I am
> guessing that reading the factory methods.
> Or would it be fine to have custom subclasses?
>
> Thanks
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>