[M3devel] small objects

[Tony Hosking]

On 8 Apr 2009, at 11:49, Rodney M. Bates wrote:

> Mika Nystrom wrote:
>>
>> Hendrik, I think Tony's and my arguments that you can't break any
>> existing code by allowing the squirreling away of integers into
>> REFANYs are pretty solid.  Pre-existing code simply can't do anything
>> useful with unrevealed REFANYs.
>
> This is only true of _unrevealed  opaque subtypes_ of REFANY,
> not of REFANY itself.   There is lots of existing code that uses  
> REFANY,
> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and
> regularly are used on it.   It is essential not to alter the  
> semantics there.

Pre-existing code won't be able to do anything useful with tagged  
REFANYs:

Suppose we have

VAR r: REFANY = SmallInteger.FromInt(0);

then

ISTYPE(r, REFANY) => TRUE
ISTYPE(r, T) => FALSE for any T # REFANY

Similarly, for TYPECASE, r will only trigger the REFANY branch.

NARROW(r, REFANY) => r
NARROW(r, T) => run-time error for any T #REFANY

VAR x: REFANY  => assignment succeeds
VAR x: T := r  => run-time error for any T # REFANY (because of  
implicit NARROW)

It is impossible to dereference an expression statically typed as  
REFANY, so there is no need for a "tagged" check on dereference.
Because a tagged REFANY cannot be assigned to anything other than  
something typed REFANY, it can never propagate to a place where it can  
be dereferenced.

> Aside from actual semantic changes, I agree with Tony that we should
> not burden any existing type with additional runtime work.  Even  
> though
> I expect small objects to support big performance gains in certain
> important cases, non-tagged references will still greatly predominate
> in most code.   Create new type(s) for tagged references.

I'm not sure that we are seeing any semantic changes at all.  And with  
Mika's definition of SmallInteger.T as a "boxed" INTEGER object  
(actually it would be a subrange for values that fit into  
BITSIZE(Word.T)-1 bits), it is essentially transparent.  It just  
happens to be a run-time optimization that unboxes the INTEGER value.


I think I can implement the compiler and run-time support for this  
very quickly.