Truffle CallNode API

[Stefan Marr]

Hi Christian:

Just a brief note after having a quick look at your patch.
I am currently relying on methods like:

public abstract Object executeEvaluated(final VirtualFrame frame, final Object receiver, Object argument);

and similar for the Unary/Binary/Ternary/KeywordMessageNodes.
I use them to pass the values that have been determined in the CachedSendNode to the actual methods.
Guess, I’ll need to rethink that as well, most likely together with the rest of the send nodes.
(Or I hack these methods into CallNode until I find a better solution just to make it work for the moment.)

Well, I’ll try to find a solution.

Thanks for your help again!
Stefan

On 30 Jan 2014, at 23:43, Christian Humer <christian.humer at gmail.com> wrote:

> 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/
> 
> 
> 
> 
> <callnode_binary.patch>

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/