[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