Re: Run-time representation of classes

"Jon Harrop" <jon@ffconsultancy.com> wrote in message
> Firstly, what are some good overviews of this subject?
>
> 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?
>


my comment:
the main reason classes are usually extended onto the end is because this
may allow much more efficiently accessing class-members, and also passing
derived classes to places expecting the superclass and having it continue to
work.


the main disadvantage to bidirectional expansion would be either this would
create weirdness for the GC (AKA: pointers are into the class in the middle
somewhere), or it would lose the advantage of being able to used fixed
offsets.


now, in my particular class/instance system, a feature had been added partly
for adding support for class-versioning (basically, so that I could
subsequently modify class layout and have old instances continue to work,
...).


which is that, basically, each slot (or field/member/instance variable/...)
handle is owned by the particular class which created it, and also keeps
track of an offset table and its assigned spot in the table. when accessing
a slot using this access mode, it goes about locating the correct table for
the object (or class, if no versioning or class-mutation is supported), and
then retrieves the offset from this table.


for example, each class could have a table of current offsets, and maybe
keep track of superclass layouts as well, so a quick loop is used to lookup
the correct table for the owner class.


this is a little more expensive than a hard-coded offset (it is actually
closer to how many systems implement interfaces), but does allow changing
physical layout as needed...


adding versioning is not much more than this, namely it involves the
addition of a table of "versions" (each version context then holding the
various offset tables, ...). each instance then containing a version number
along with the class pointer (applying a group of changes to an object
creates a new version context, and a new version number).




however, my system does make use of fixed offsets when possible (namely: for
classes which have never been modified), since the speed difference is
notable...




actually, ammusingly I implement interfaces rather differently to how many
systems implement interfaces.
prototype-OO features are allowed as well, but actually make use of yet a
different set of mechanisms.




> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?u
> [I wouldn't think a GC would care so long as it could tell what was a
> pointer. -John]


yes, pretty much.


for a conservative GC, we scan the whole object anyways...
and for a precise GC, there is normally a mark handler which usually
iteraters over and marks all the references, and this makes little
difference regardless of how they are organized in the object...

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