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

[Christian Humer]

Hi Stefan,

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().

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

Your definition of the literal nodes do not require a method with the
@Specialization annotation. Just implementing the execute methods should be
fine since they are already stable (they do not specialize anymore) after
parsing. (This can also be done the simple language [1], I will change that)

[1]
http://hg.openjdk.java.net/graal/graal/file/aeeab846e98c/graal/com.oracle.truffle.sl/

- Christian Humer


On Tue, Oct 1, 2013 at 3:31 PM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
>
> In order to use return-type specialization for TruffleSOM, I extended the
> TypeSystem [1] to include more than 'som.Object'. My first experiment using
> it is to introduce typed literal nodes with specialized methods for the
> native type.
>
> However, I ran into some issues and would like to verify whether I am
> understanding the ideas behind it correctly.
>
> The type system now includes the native Java types for the literals that
> map directly to them, and the SOM Object type (int, BigInteger, double,
> String, boolean, som.Object).
>
> For each of these types I created TypeChecks and TypeCasts that basically
> are supposed to pair up native types and their wrapped counter parts, for
> example int and som.Integer.
> That seems to work well, and the generated TypeSystem does look ok.
> However, then I added `boolean isObject(j.l.Object)` and `som.Object
> asObject(j.l.Object)` to the type system, and the generated type system
> overrides these methods. [I tried to mark the methods as final, but that
> doesn't prevent the code generator from creating the unadapted variants. It
> leads just to a compilation error because of the overrides.]
>
> The intent of the TypeCast function asObject(.) on line 151 [2] was to
> convert between the unboxed native types and the SOM object types as
> necessary. But since the generated type system class includes a generic
> version of this TypeCast, I am wondering whether that is the correct
> approach.
>
> When finally implementing the specialized literal nodes, I got the feeling
> that it should indeed be possible to customize the asObject TypeCast,
> because the generated specialized literal nodes had generated
> `executeGeneric(frame)` functions, which seemed to do the right thing if my
> TypeCast would have been preserved.
> But with the generic TypeCast in place, I had to work around it, and for
> instance for my string literal node, I needed to implement a custom
> `executeGeneric(frame)` function (cf. line 19 in [3]).
> Comparing the generic with my custom execute methods shows that the custom
> one is probably a little more efficient, but it feels like I am working a
> bit against the framework and thus, I am wondering whether it is the
> correct approach.
>
> So, my general questions is whether I am using the type system correct,
> i.e., is the intent to use it to map unboxed and boxed types as in my case.
> And furthermore, whether there is a design reason to provide a generic
> type cast for `asObject()` that prevents custom versions of it.
>
> Thanks
> Stefan
>
>
>
> [1]
> https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java
> [2]
> https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java#L151
> [3]
> https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/StringLiteralNode.java#L19
> --
> 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
>
>