Re: Run-time representation of classes

On Tue, 27 Jan 2009 22:05:05 +0000, Jon Harrop <jon@ffconsultancy.com>
wrote:


>Firstly, what are some good overviews of this subject?


Most modern compiler texts will cover it. AFAIK, there aren't any
profound new ideas being floated anywhere ... it's basically a choice
of whether to flat extend the original structure or merge competing
structures so the result has only one slot with any given name.




>Secondly, I have been thinking about extending my compiler from supporting
>algebraic datatypes to supporting classes and I believe you need a uniform
>representation of subtypes so the conventional solution is to add data to
>the end of the representation of the base class in order to create the
>representation of a derived class. I assume a GC would be happier if the
>reference types in a class were located contiguously so I am wondering if
>there is any merit in extending the representation of a base type both
>downwards and upwards in memory, one direction for reference types (which
>are then held contiguously) and the other direction for value types (which
>the GC will not touch). Is that a good idea?


There would probably be a slight speed advantage to having all the
references contiguous, but I think that for non-trivial structuring it
is probably more trouble than its worth.


In general it isn't possible to guarantee contiguous references in a
structured type without simultaneously disallowing the embedding of
other structured types within it. Consider the following (using C for
a common language):


    typedef struct
    {
        Something *r;
        int i;
    } A;


    typedef struct
    {
        SomethingElse *r;
        float f;
    } B;


    typedef struct
    {
        A a;
        B b;
    } C;




Putting aside that C isn't OO, what happens when you have an object of
type C and try to pass it's member 'b' to a function expecting a type
B? If you have rearranged the data members of C to keep all the
pointers together, then you have no B object. Are you going to
generate a temporary B object on the fly? Or maybe define some kind
of B' object that is compatible with B but whose layout matches what
you've done to B in C? And what if there are other incompatible uses
of B?


It just doesn't pay to deal with these kinds of questions. Instead,
lay out your objects in whatever way is convenient and worry about how
to quickly convey the object layout to the GC.




Most texts cover basic GC and creating pointer/reference maps for your
structured types. That works well provided the maps are simple and
fast to decode (e.g., byte or word maps rather than bits). A slightly
faster, but more complex, method is to generate a customized scanning
function for each type that knows where to find embedded references
... not all texts mention this method.


GC using scanning functions is a little more generic ... IMO it's a
little cleaner for the collector to just call a function than to embed
knowledge of maps and their interpretation into it. Obviously you can
combine the two ideas easily enough.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.