How to do AST inlining of method calls?

[Thomas Wuerthinger]

Stefan,

there are three ways to work with Truffle frames:
a) VirtualFrame instances that are guaranteed to be virtualised and therefore have severe restrictions.
b) MaterializedFrame instances that can be used like normal Java objects.
c) PackedFrame instances that speculate on not being used by the method they are transferred to.

It is always possible to create a MaterializedFrame instance from a VirtualFrame instance via a call to Frame.materialize [1]. However, it should be avoided wherever possible as the performance of virtual frames is an order of magnitude better than the performance of materialised frames. The reasons for the restrictions around virtual frame is to provide a predictable performance experience when dealing with frames.

In the problem you describe below, the main question is why the method with the frame as a parameter cannot be inlined. Can you send the command line for triggering the problem?

- thomas

[1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/com.oracle.truffle.api/javadoc/com/oracle/truffle/api/frame/Frame.html#materialize()

On Sep 12, 2013, at 1:23 PM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
> 
> On 11 Sep 2013, at 02:31, Andreas Woess <andreas.woess at jku.at> wrote:
> 
>> On 11.09.2013 01:20, Stefan Marr wrote:
>>> Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced.
>>> This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining.
>> This is the correct approach. Note that you should duplicate the tree in
>> its uninitialized state (e.g. in the constructor of the method root node
>> and keep a copy there) so that the inlined tree specializes for that
>> particular call.
> 
> Right, that's what I do. Currently, the only specialization is for monomorphic and polymorphic sends.
> And the copying of tree nodes for message sends will create an uninitialized message send node.
> 
> 
>>> Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object.
>>> This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment.
>> Again, this is this the right way. You should get a stack trace with the
>> approximate location of the problem.
> 
> After experimenting more with this, and trying to understand what the issue is, I start to belief that the heuristic encoded in VerifyFrameDoesNotEscapePhase is just to simple. After removing the check for passing the frame on to a method, the benchmarks run to completion. So, I have the feeling (but without being very confident) that I use the frame classes in a more or less correct way.
> 
> I am wondering whether there could just be an annotation that tells the check in VerifyFrameDoesNotEscapePhase that a frame passed to a certain method is not problematic?
> The reason why I think that the heuristic is too simple is that method call boundaries are a to strong constrained. Since not all calls are inlined in the graph, the check becomes restrictively conservative. I experimented with just duplicating code to give the check more information, but as soon as I get to a truly polymeric send site, I still get into trouble…
> 
> I wonder why such a simple issue is not problematic in the other Truffle-based languages being implemented. Could I annotate the frame creation with something that marks it as unproblematic?
> 
> 
> For others interested in the code for inlining methods, the following commit should be the most relevant piece:  https://github.com/smarr/TruffleSOM/commit/1edba8692fd0a0ffe78510f45597c6f8a8a6cadf
> The cloning of nodes is introduced here: https://github.com/smarr/TruffleSOM/commit/851549ac9d04315a755a1851a002e7b1bd96e55c
> 
> Best regards
> Stefan
> 
> 
> -- 
> 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
>