Re: Run-time representation of classes

ftu@fi.uu.nl (Dick Wesseling)
31 Jan 2009 04:22:34 GMT

          From comp.compilers

Related articles
Run-time representation of classes jon@ffconsultancy.com (Jon Harrop) (2009-01-27)
Re: Run-time representation of classes cr88192@hotmail.com (cr88192) (2009-01-30)
Re: Run-time representation of classes gneuner2@comcast.net (George Neuner) (2009-01-30)
Re: Run-time representation of classes armelasselin@hotmail.com (Armel) (2009-01-30)
Re: Run-time representation of classes ftu@fi.uu.nl (2009-01-31)
Re: Run-time representation of classes michael@schuerig.de (Michael Schuerig) (2009-02-02)
Re: Run-time representation of classes cr88192@hotmail.com (cr88192) (2009-02-03)
Re: Run-time representation of classes gneuner2@comcast.net (George Neuner) (2009-02-04)
Re: Run-time representation of classes michael@schuerig.de (Michael Schuerig) (2009-02-05)
Re: Run-time representation of classes cr88192@hotmail.com (cr88192) (2009-02-05)
Re: Run-time representation of classes cppljevans@suddenlink.net (Larry Evans) (2009-02-07)
[2 later articles]
| List of all articles for this month |
From: ftu@fi.uu.nl (Dick Wesseling)
Newsgroups: comp.compilers
Date: 31 Jan 2009 04:22:34 GMT
Organization: Compilers Central
References: 09-01-055
Keywords: OOP
Posted-Date: 01 Feb 2009 16:04:17 EST

Jon Harrop <jon@ffconsultancy.com> writes:


> 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


Sorting the fields in a class so that all pointers are contiguous is
a good idea. Consider the following loop which might occur in the
mark phase of a GC:


                n1 = class.totNrFields;
                for (i=0; i<n1; i++) {
                        f = field(currentObject, i)
                        if (isapointer(f)) {
                                follow(f)
                        }
                }


versus:
                n2 = class.nrPointers;
                for (i=0; i<n2; i++) {
                        follow(field(currentObject, i);
                ]


This saves the isapointer() test and n2 can be considerably smaller
than n1.


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


I did this optimization for my Java GC and there it was sufficient to
separate the pointers and primitive fields that each subclass adds to its
parent class. The loop was more or less


                class = currentOject.class;
                do {
                        parent = class.super;
                        bias = parent.totNrFields;
                        n2 = class.nrPointers;
                        for (i=0; i<n2; i++) {
                                follow(field[i+bias])
                        ]
                        class = parent
                } while(class != objectClass); // Root of hierarchy reached?



Post a followup to this message

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