GC refactor ahead

Andrew Whitworth wknight8111 at gmail.com
Fri Dec 4 16:26:12 UTC 2009


On Fri, Dec 4, 2009 at 11:00 AM, Kevin Tew <tewk at tewk.com> wrote:
> Coding policy based intergenerational management will be violated (creating
> GC bugs) by adding new features and refactoring old code.
>
> Unless I'm missing something obvious this seems likely to multiply the types
> of bugs that constant PMCS introduce.

Let me try and explain better what I am thinking:

We'll have at least two functions to allocate a new PMC header:
Parrot_new_normal_pmc and Parrot_new_immortal_pmc. On any field access
we'll have a write barrier setup that can identify the generation of
the child PMC, and if the generation of the child is the same as the
generation of the parent, we don't need to update the
intergenerational list. We only need to update the intergenerational
pointer list when a pointer is "intergenerational".

So if we call Parrot_new_immortal_pmc() to create the parent, and we
call it again to create the child, we've manually shown the
relationship that the two are in the same generation and we don't need
integenerational pointers. However, if the parent is immortal and the
child is normal, the write barrier will detect that and add the
intergenerational pointer record.

We could detect the mortal/immortal status of a PMC by checking a flag.

So there would be no manual modifications to the intergenerational
pointer list, and there would be fewer bugs because the differences
would be detected automatically (currently, differences aren't
detected or accounted for at all, hence all the bugs). We can all keep
in mind that this is an optimization, something that we should be able
to apply after we've created the generational GC and after we've
inserted write barriers in all the proper places. There are lots of
similar optimizations we could try once we have a good base system in
place.

--Andrew Whitworth


More information about the parrot-dev mailing list