[Truffle] Generated type system overrides isObject()/asObject() methods.

[Stefan Marr]

Hi Christian:

On 01 Oct 2013, at 18:02, Christian Humer <christian.humer at gmail.com> wrote:

> As a workaround please do not use class names that are already used in the java.lang package because the code generator currently produces erroneous code for them. (i am working on a fix for that)
> This should also solve the described conflict with asObject().

I already experimented with renaming som.Object to SOMObject, and ran into another issue.
The generated `expectSOMObject()` is throwing the UnexpectedResultException in a generated `executeGeneric()` method.
And that exception remains unhanded. So, well, again, out of luck.

More below.

> The @TypeCast and @TypeCheck annotations should not be used to customize the boxing behavior of a type. It is currently not possible to define custom boxing for primitive types in the TypeSystem. But this is on my TODO list for the next weeks.
> The current workaround for boxing is to define primitive types and boxed types in the type system and specialize for each type separately. There is also an experimental feature called implicit casts which could help you with a workaround. 

Ok, for my understanding: What is the intent of the TypeSystem? Which kind of types should it contain? And, how do the types related to each other?

One thing that I am a little confused about is that the generated code does not seem to have any notion of type hierarchy or so. While there are indications in the TypeSystem comments, that the list should indicate some order, and that a subtype should go before a super type (if I recall correctly), my SOMObject class does not seem to be recognized as the root type. Consequently, the UnexpectedResultException is thrown in a situation where it should never happen.

If I try to think about what I would want to write down in the TypeSystem, I would probably want to indicate a mapping between box and unbox types as well as the root type. That way, I imagine, `expectSOMObject()` would always succeed, because the SOM language has one root type (Object) and does not allow for any other kind of things outside that hierarchy. [I guess for languages such as Java, the TypeSystem definition would need to allow for different things.]

At the moment, my understanding is rather that the TypeSystem contains a list of types for which operations can be specialized. (That's derived from your comment above.)


> However I think you should first think about which kind of specializations you want implement and then think about the actual types you will have to use.  I would recommend to start with generic versions of your operations and then specialize/optimize your operations step by step.
> Could you briefly introduce or point me to some operations/nodes you want to optimize? 
> Its also possible that Truffle-DSL is not the right tool for you. 

Well, in general, TruffleSOM is functional. So, I don't plan to implement any new 'generic operations'. My current goal is to get it fast, and to make the compilation on top of Graal work properly.

[I still haven't sorted out my VirtualFrame escaping issues, had hope some specialization could make the partial evaluator a little happier.]

With fast, I mean, I want a TruffleSOM that is as fast as the C++-based SOM interpreter, and ideally as fast as the PyPy/RPython-based SOM. But I am still way off of that.

To get there, I envision I need to specialize at the very least for integers:
 - access to frame slots (guided by SimpleLanguage's Read/WriteLocalNode)
 - message sends (I already got a monomorphic/polymorphic/megamorphic message nodes and started experimentation with inlining of monomorphic messages. I also bit the bullet an added a nodes for IfTrue/IfFalse messages on booleans)
 - primitives

The primitives (addition, subtraction, array access operations, etc, e.g. [1]) are I think the most important issue right now. At the moment, their implementation uses a couple of indirections that are probably not really helping the optimizer to remove any overhead.
So, what I envision is that all primitives for addition should become a truffle node with the various specializations.
A SOM method would than refer to just the truffle node implementing that primitive, instead of being something custom made. With the inlining functionality, I should be able to get monomorphic message sends to primitives closer to optimal performance.
But to get there, I was first trying to understand the specialization techniques provided by Truffle better, and how the TypeSystem fits in there. Because, so far I ran into a lot of dead ends.

Thanks for the help
Stefan

[1] https://github.com/smarr/TruffleSOM/blob/master/src/som/primitives/IntegerPrimitives.java

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