gc_ms2_tuning branch

Vasily Chekalkin bacek at bacek.com
Wed Sep 29 09:06:52 UTC 2010


On Tue, Sep 28, 2010 at 11:29 PM, Luben Karavelov <karavelov at spnet.net> wrote:
> On Tue, 28 Sep 2010 14:52:12 +1000, Vasily Chekalkin <bacek at bacek.com>
> wrote:
>
> If we have 3 generations (as I understand the work done by vassily)
> can't we have:
>
> a. 1 array for ancient generation
> b. 1 array for old generation
> c. 1 array for new generation  (if we need it)
> d. 1 array that holds objects from old and ancient generations that
>   were modified since last GC run.

It is exactly what I have in gen_gc branch. But implemented using
linked lists, not arrays.

> If we use this scheme, the object that have to be checked on minor GC
> run
> (checking only the youngest object) is to check objects in arrays "c"
> and
> "d", and then we empty array "d". What we also gain in this approach is
>
> that  we do not swap vtables back on older objects - when they are old
> or ancient then do not move back in younger generation.

What about old-to-young pointers? After we move some aggregate object
into older generation we have to:
1. Move all dependant objects into same generation (as currently in
gen_gc branch).
2. After handling write_barrier call either move it back to young
generation (as in branch) or move all dependant objects into old one
(which is doable).

-- 
Bacek.


More information about the parrot-dev mailing list