Closed Bug 719478 Opened 12 years ago Closed 9 years ago

Make the cycle collector replayable for debugging

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

This is mostly a silly idea, but maybe it makes some sense.  With smaug's patches, the CC will do work to improve the CC as it runs, so you could get one run that is bad, then it is good again.  It would be nice to be able to capture all CC logs for slow runs.  But we don't want to do that all of the time, because logging makes CCs slower, which makes it hard to figure out which ones are actually slow.

One solution to this would be to have an option, perhaps at compile time, to go into a "replayable CC" mode.  After the CanSkipInCC pruning is done, from there until CollectWhite is called, the CC should not have any side effects.  So what we do is, every time before we do that we make a copy of the purple buffer (which should be fairly fast), then start a timer.  Then before we go into CollectWhite, we check if the timer is longer than some threshold.  If it is, then we restart the CC, except this time with a listener that is logging to a file.

This may require some fiddling with exactly how the CanSkipInCC stuff is doing, but it seems like it would be doable.  The question is whether it would be worthwhile.
This could also be useful for other kinds of automated tests of the results of the CC, but I'm not sure we have anything like that right now.
Blocks: 723783
This is still kind of a cool idea, but I don't think it is really worth landing. I have hacked up something like this locally one time.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.