[Vm-dev] Root flag & root objects

Eliot Miranda eliot.miranda at gmail.com
Sat Feb 21 17:14:33 UTC 2009


The root bit must mark all objects, and the root table must contain all
objects thata) are in old space and
b) refer to objects in

i.e. to find all roots into youngSpace the GC must be able to find all
candidates in the root table.  The root bit is a flag that saves searching
the root table when adding a new root to the root set.

So yes, when creating a new image, all objects are in oldSpace and so no
objects need to be in the rot table or have their root bit set.

This raises another point of ignorance for me.  I would have thought that it
is OK for the root bit to be set or the root table to contain objects that
are not in old space or do not/no longer refer to objects in youngSpace
because the GC will remove these from the root table on GC.  But I don't see
where objects get cleared from the rootTable.  I only see the RootTable
being voided when it gets full (rather drastic).  Can anyone say if this
happens or not, and if so, where it happens?

Looks to me like either markAndTrace: or a specialized version, say
markAndTraceRootObject:, should maintain a flag, refersToYoungObject, and
clear the object from the rootTable (and clear the root bit)
if refersToYoungObject is false at the end of the scan.   But with the
pointer reversal algorithm it is hard to see where to maintain this flag.

Can those who know enlighten this ignorant soul?

TIA

On Sat, Feb 21, 2009 at 4:42 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> Hi,
> i'd like to ask, is it safe to clear the root flag for every object in
> system.
> I'm artificially creating a new image, and i'd like to know, what
> objects should be marked as roots initially, or VM can care about it
> itself?
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090221/59a9ff0a/attachment.htm


More information about the Vm-dev mailing list