GC refactor ahead

[Kevin Tew]

Pmichaud is hinting at my primary concern.

Intergenerational pointer invariants should not be enforced manually.

Constant PMCS are a headache.  We have had lots of "GC bugs" because 
developers hung non-constant objects off of a constant pmc.

This is even worse if a specific PMC type is used in both constant and 
non-constant settings.

1. You can't separate objects into separate generations unless you can 
track intergenerational pointers.

2. Tracking (or eliminating) intergenerational pointers based on 
"developer coding policy invariants" (ie Constant PMCs can ONLY contain 
or point to constant PMCS)  is essentially reverting memory management 
responsibilities back to the developer.

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.

Kevin


Patrick R. Michaud wrote:
> On Fri, Dec 04, 2009 at 10:52:19AM +0000, Allison Randal wrote:
>   
>> [...] We can
>> also use a function pmc_new_methuselah for objects we know are
>> created at interpreter startup that will live until interpreter
>> death (there's no reason to run GC on those during operation at
>> all). Like constants, we require that all children of adonis or
>> methuselah PMCs must be allocated from the same pool(s). 
>>     
>
> ...when we're allocating a new PMC, how can we know in advance
> that it will end up being a child of a methuselah PMC?  Or do we
> not need to know this (if we don't need to know it, how does
> the requirement get met)?
>
> Pm
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>