On Jan-10, Leopold Toetsch wrote: > Also I was thinking of: trace_system_areas could be run last in marking > and if it finds some unanchored objects, it could print a warning, so we > could really check, if we ware safe.
That's what defining GC_VERBOSE in parrot.h will give you right now, and it's usually too noisy to be useful. For some reason, it seems to be very common to have old PMC pointers lying around on the stack. (Which is a further argument against it, I guess -- the stackwalk may hang onto significant chunks of memory and cause later allocations to fail unnecessarily. That's true of most of the suggested schemes to some degree, but GC_VERBOSE gives an estimate of how bad it is for stackwalking. A poor estimate, though, since most of the stale pointers it finds are probably not holding onto much memory, but it can only get worse.) I am committing the summary I wrote into parrot/docs/dev/infant.dev, since I see that as the original idea behind the .dev files -- to record the justifications for design decisions along with the other variants, so people don't need to recreate them quite as often. On the other hand, the other part of the impetus for *.dev files was to pair them up with actual source files, but so far that doesn't appear popular enough to actually happen. (I have mixed feelings tending toward the negative about that idea anyway.) The summary should really be updated to reflect some of the further discussions we've had. I ought to add at least a section on hybrid schemes (eg anchor what you can, have a temporary root for the rest), interaction with the (weakened) finalization guarantees needed for Perl6, and the schemes for allowing some of the listed approaches to work in the presence of longjmp() and recursive calls. But I don't have the time at the moment. Anyone else is more than free to update it once it's checked in. [And it isn't yet -- looks like /tmp is full on the cvs server at the moment.]
