TruffleSOM with SimpleLanguage-Style Call Caches

[Stefan Marr]

Hi:

I finally got around to change TruffleSOM to use call caching and inlining based on the new SimpleLanguage examples.
The current version uses specialized classes for unary, binary, ternary, and keyword messages to allow for a specialization of messages for primitive operations based on the argument types. So, this part of the design hasn’t changed much from the last iteration. However, the way primitive operations (‘builtins’ in SL terminology) are handled has changed.

Below, you’ll find a brief comparison of the last two design iterations, and my observations, and at the end, I got another of those ‘escaping frames’ issues, I haven’t been able to solve yet.

Direct vs. Indirect Monomorphic Checking
———————————————————————————————————————-

In the last design iteration, I tried to use the polymorphic behavior of nodes supported by the TruffleDSL to my advantage. However, since state-based guards are currently not supported, it was not possible to implement the check for a monomorphic send using only the TruffleDSL. However, I think, the general design might still have a few benefits, since it avoids an additional node in the AST. To make that a little more explicit, let’s consider the following example:

    Calculator>>#add: a to: b = ( ^ a + b )

This would result in an AST roughly looking like this:

     Method(RootNode)
     +- BinaryMessage
         +- receiver = FieldReadNode
         +- argument = FieldReadNode

After specialization, it would look like this:

    Method(RootNode)
    +- AdditionPrimNodeInteger
            (next)-> AdditionPrimNodeDouble
                  (next)-> AdditionPrimNodeUninitialized
         +- receiver = FieldReadNode
         +- argument = FieldReadNode

Now, the DSL is currently not able to support my approach of having this unified with standard inline caching for instance in case Strings are ‘added’, were ‘+’ is not implemented in AdditionPrimNode as a specialization but as a normal Smalltalk method.

So, I switched to the SimpleLanguage approach, and now the AST looks like this after specialization:

    Method(RootNode)
    +- BinarySendNode$CachedSendNode (current)-> AdditionPrimNodeInteger
            (next)-> BinarySendNode$CachedSendNode (current)-> AdditionPrimNodeDouble
                  (next)-> BinarySendNode$CachedSendNode (current)-> BinarySendNode$InlinableSendNode (callTarget)-> (String>>#+:)
                       (next)-> BinarySendNode$UninitializedNode
         +- receiver = FieldReadNode
         +- argument = FieldReadNode

The nice thing about this design is that the whole question of monomorphic sends is completely handled by the *SendNode’s CachedSendNode implementations. And then, all kind of specialization happens after that.
However, I am not sure whether this indirection is unproblematic for compilation.

Another problem is that in my current implementation much of the SendNode implementations is duplicated code, slightly adapted to the different types and signatures for the Unary/Binary/Ternary/Keyword message nodes.
Similarly, the specialization for the n-ary message nodes also forces me to duplicated code for the variants for inlined methods. All in all, not very nice, but with Java’s restricted support for generics, I also don’t see a lot of options to avoid it.


Escaping Frames
——————————————-

Following previous experiences with Graal reporting escaping frames, I tried to identify all loops that lead to a call to `executeGeneric(.)` to make sure they are marked with @ExplodeLoop. However, in this case I either missed one or this strategy is not sufficient.

Any other general strategies that would help to identify potential issues for escaping frames?

Thanks
Stefan

The latest code can be obtained with:

    git clone --recursive https://github.com/smarr/TruffleSOM.git
    cd TruffleSOM
    ant jar
    cd $GRAAL
    ./mx.sh --vm server vm -Xbootclasspath/a:../TruffleSOM/build/classes:$SOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/Smalltalk ../TruffleSOM/Examples/Benchmarks/Loop.som
    

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