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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
