Jeremy Hylton wrote:
"MTK" == Matthew T Kromer <matt@zope.com> writes:
MTK> A side effect of shutting off the garbage collector is that you MTK> can have some storage leaks. We're working on being able to MTK> re-enable the garbage collector so that you don't exhaust MTK> memory over time.
Do you have any more idea about what shutting the garbage collector off achieves? In practice, the garbage collector's most common effect is to turn latent bugs into manifest bugs; a bug has trashed part of memory and the garbage collector just happens to find it first. If you turn GC off in these cases, you run a little longer, but you're running with corrupted memory.
Jeremy
Well, one suspicion I have is that (aside from memory corruption caused by the compiler sack size bugs and the frame setup bug in 2.1 when handling exceptions) ExtensionClasses are providing bogus data to modules which aren't checking the flags to see if the GC fields are populated. Some of the people who have tried the modified extensionclass.h which pads out the type object to align it with the 2.1 type object THINK they have seen a reduction in crashes, but these same folks also have not applied fixes for the two known bugs. Soo... if shutting off GC extends time between crashes for some folks from every 15 minutes to 3 times a day, my advise is to shut off GC.