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

[Stefan Marr]

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