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