[Vm-dev] Why the context become a root

John M McIntosh johnmci at smalltalkconsulting.com
Tue Nov 20 00:00:13 UTC 2007


On Nov 19, 2007, at 3:32 PM, Andreas Raab wrote:

> Mathieu Suen wrote:
>> Ok so IIRC adding object into the root table that do not contain  
>> young object do not bug the system.
>
> Yes.
>
>> but every object that contain young object should be inside this  
>> table otherwise the gc crash?
>
> Yes.
>
>> Next question is where do the root table is update to remove the  
>> object that dose not contain young one?
>
> It's expensive. For every store into the old object you'd have to  
> check whether it is still a root (which is a linear scan over the  
> object itself so if it is large it'll be very slow).

VW will stick the object and the slot into a structure.  This leads to  
the root table dynamically growing based on what is going on. The  
downsize for years was you could  make
the VM crash by causing this root table to grow too fast before some  
other task could do a full GC and tenure the problem objects. I  
understand this issue has been fixed/ or worked around
in current versions of VW. This of course make Squeak slower if you  
stick a large collection object into the root table.   A fix for this  
is to use a dynamic memory policy which considers root table size  
versus scans/etc then invokes a tenure.   In some Squeak code you  
might also find the workaround of allocating a large collection then  
doing a full GC to avoid the excessive root table scan.

>
>> I suppose when a full gc is trigger but is there any other moment?
>
> Yes. When tenuring, the roots table is cleared. A couple of days ago  
> I toyed with a variant of the collector which used generation aging  
> (e.g., tenures objects after it survived so many GCs) and the main  
> task was deciding whether tenuring should make all tenured objects  
> root or if it should actually scan them (I think it needs to).

Didn't early tek system use this, they had 7 generations of old  
space....


>
>
> What are you working on?
>
> Cheers,
>  - Andreas

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================




More information about the Vm-dev mailing list