I don't understand the GC root table

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

I don't understand the GC root table

Mariano Martinez Peck
 
Hi guys. I usually thought that the root table of the GC was the #specialObjectsArray. Now, checking a little bit the VM and image side, it seems I am totally wrong.

"Smalltalk rootTable" answers an array that I cannot understand how such array can be the root. Where are the references to all the system from such an array?  there is no reference to specialObjectsArray for example.
Even more, the table seems to be full of weird stuff, such as "an OController", a lot of "a Text" instances about my workspaces stuff, Colors, Morhpic, etc....

Smalltalk isRoot:  Smalltalk  specialObjectsArray -> false
Smalltalk isRoot: true -> false
Smalltalk isRoot: false -> false
Smalltalk isRoot: nil -> false

so...I am lost.

Thanks in advance for any help.

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand the GC root table

Stefan Marr

Hi:


On 26 Sep 2011, at 11:12, Mariano Martinez Peck wrote:

> Hi guys. I usually thought that the root table of the GC was the #specialObjectsArray. Now, checking a little bit the VM and image side, it seems I am totally wrong.

The `roots` are usually something VM internal.
You will have to find that in the Slang sources yourself, but a look at what we have in the RoarVM might help you to find it: https://github.com/smarr/RoarVM/blob/master/vm/src/objects/roots.h

class Roots {
  Oop specialObjectsOop;
  Oop nilObj, falseObj, trueObj;
  Oop freeContexts, freeLargeContexts;

  Oop receiverClass;
  Oop newNativeMethod;
  Oop methodClass; // unused?
  Oop sched_list_class;
  Oop dnuSelector; // for debugging

  // these get sent for control transfers
  Oop _activeContext;
  Oop _method;
  Oop _theHomeContext;
  Oop receiver;
  Oop messageSelector;
  Oop newMethod;
  Oop lkupClass;
  Oop running_process_or_nil;
 
  Oop emergency_semaphore;
};

And that is basically only the stuff that the interpreter needs during execution, and which might not be reachable by other means anymore. As you can see, the special objects array is part of the roots object, too.

> "Smalltalk rootTable" answers an array that I cannot understand how such array can be the root.
In my old MVC image there is not rootTable, but I would expect it to be a primitive which returns the content of a data structure similar to ours.

Best regards
Stefan


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand the GC root table

Andreas.Raab
In reply to this post by Mariano Martinez Peck
 
The rootTable is used during incremental GC. Its contents are those objects in old space that are roots for objects in new space (see ObjectMemory>>beRootIfOld:). It has nothing to do with the (global) roots of the interpreter; in fact the root table is cleared right at the beginning of fullGC (see senders of #clearRootsTable). The global roots are explicitly enumerated in Interpreter>>markAndTraceInterpreterOops.

Cheers,
  - Andreas

On 9/26/2011 11:12, Mariano Martinez Peck wrote:
 


Hi guys. I usually thought that the root table of the GC was the #specialObjectsArray. Now, checking a little bit the VM and image side, it seems I am totally wrong.

"Smalltalk rootTable" answers an array that I cannot understand how such array can be the root. Where are the references to all the system from such an array?  there is no reference to specialObjectsArray for example.
Even more, the table seems to be full of weird stuff, such as "an OController", a lot of "a Text" instances about my workspaces stuff, Colors, Morhpic, etc....

Smalltalk isRoot:  Smalltalk  specialObjectsArray -> false
Smalltalk isRoot: true -> false
Smalltalk isRoot: false -> false
Smalltalk isRoot: nil -> false

so...I am lost.

Thanks in advance for any help.

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand the GC root table

Stefan Marr

Hi:

On 26 Sep 2011, at 13:22, Andreas Raab wrote:

> The rootTable is used during incremental GC. Its contents are those objects in old space that are roots for objects in new space (see ObjectMemory>>beRootIfOld:). It has nothing to do with the (global) roots of the interpreter; in fact the root table is cleared right at the beginning of fullGC (see senders of #clearRootsTable). The global roots are explicitly enumerated in Interpreter>>markAndTraceInterpreterOops.

Not sure whether it is worthwhile to change such details, but I belief the standard terminology would be 'remembered set'. At least that is the typical name for recorded references between different object sets maintained separately, AFAIK.

And it could avoid confusion.

Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand the GC root table

Mariano Martinez Peck
 
Thanks guys. Indeed, I was totally confused. Maybe 'rootTable' is a little bit confusing...  What do you think about changing at least the selector from image side (Smalltalk rootTable)? or it would be even more confusing?

Thanks!

On Mon, Sep 26, 2011 at 2:06 PM, Stefan Marr <[hidden email]> wrote:

Hi:

On 26 Sep 2011, at 13:22, Andreas Raab wrote:

> The rootTable is used during incremental GC. Its contents are those objects in old space that are roots for objects in new space (see ObjectMemory>>beRootIfOld:). It has nothing to do with the (global) roots of the interpreter; in fact the root table is cleared right at the beginning of fullGC (see senders of #clearRootsTable). The global roots are explicitly enumerated in Interpreter>>markAndTraceInterpreterOops.

Not sure whether it is worthwhile to change such details, but I belief the standard terminology would be 'remembered set'. At least that is the typical name for recorded references between different object sets maintained separately, AFAIK.

And it could avoid confusion.

Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525




--
Mariano
http://marianopeck.wordpress.com