Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic: > PMCs that *do* need a special mark() are troublesome; they may contain > pointers to non-constant PObjs that *do* need live marking, lest they get > swept away during the second half of GC. If these constant PObjs don't get > marked, there's a problem.
Constant PMCs that point to non-constant items are IMHO just a bug. The problem is that when their live bit is set, it isn't cleared, because - as you have mentioned too - the constant PMC pool isn't swept. Therefore they don't propagate their liveness. Ergo: all children of constant PMCs have to be constructed as constants too. This could be checked during the very first GC run (turned on with GC_DEBUG), but only if the PMC had a proper mark vtable. > Allison suggested "Hey, why not register all constant PMCs when you grab a > new constant PMC header?" and that's an easy patch to write. > option is to walk through the constant PMC pool at the start of the mark > phase to look for PMCs with the mark flag set and call those directly. > (That could simplify some other operations; this could be the root set > itself, but that's a mere detail.) All these workarounds render the advantage of constant items towards zero. You get that workaround much cheaper by ignoring the constant flag during object construction and never use constant pools. > Another concern to me is that I can't convince myself that the "HEY I AM A > CONSTANT" flag gets stored in PBC when we freeze such a PMC or gets > restored when we thaw that PMC. While not propagating the constness during freeze/thaw is undesirable, it wouldn't be a problem, if the PMCs have proper mark vtables. > -- c leo
