Closed
Bug 719478
Opened 12 years ago
Closed 9 years ago
Make the cycle collector replayable for debugging
Categories
(Core :: XPCOM, defect)
Core
XPCOM
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.
Reporter | ||
Comment 1•12 years ago
|
||
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.
Reporter | ||
Comment 2•9 years ago
|
||
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.
Description
•