[M3devel] small objects

[Rodney M. Bates]

Without language changes, this could be useful.  It does use two
words instead of one, with always one or the other being wasted.
But in my 11-to-1 example, it would give 11-to-2 savings--not to be
sneezed at.

One limitation it has is, to get the benefit, you have to stored the
two-word record itself embedded wherever the pointer would have
been, not out in the heap.

So it's not a reference type and thus can't be opaque.   No type
unsafely here, but client code can not be prevented from breaking
the abstraction.   There are places in the M3 distribution where
a non-reference type has a comment (* Treat as opaque *).

Jay wrote:
> Um, what do folks think of, like:
>  
> struct
> {
>     void* Type;
>     union
>     {
>        size_t Integer;
>        void* Pointer;
>      } Value;
> } Variant;
>  
> ?
> You know -- something that is two pointers, one pointer for the type, 
> one for the value or integer?
> void* Type would actually be a pointer to something actually defined 
> and elaborate.
>  
> Obviously this is twice as large, not as small as it could be, but 
> much more general and portable. No need to determine how many of bits 
> can be the tag.
>  
> And hope/assume for perf that such a small struct is passed in registers.
> On x86/NT 4 and 8 byte structs I think are.
>  
> Type could also be an integer, index into some table, with some 
> predefined values.
> #define TYPE_INTEGER 0
> #define TYPE_FLOAT 1
> #define TYPE_DOUBLE 2
> #define TYPE_ADDRESS 3
>  
> more generally the union would have a float, and maybe a double on 
> 64bit platforms.
>  
> OR, on 64bit platforms, you probably can, with some porting work, 
> dedicate a whole 8 bits or so to a type index, and still the thing in 
> one "word". How many bits of address space does any 64bit platform 
> these days or forseeable future actually implement?
>  
> But 32 bits doesn't seem big enough to afford that, and still this is 
> a portability problem -- anything less than a full pointer.
>  
>  - Jay