Mon, 29 Apr 2002 18:07:14 -0400
>>>>> "NS" == Neil Schemenauer <firstname.lastname@example.org> writes:
NS> Jeremy Hylton wrote:
>> I've noted before that it doesn't make much sense to invoke GC
>> unless there is at least one deallocation; you can't reclaim
>> anything if there are no DECREFs.
NS> It's easy to add a decref counter. It doesn't seem to help much
NS> though based on my limited testing. The standard test suite
NS> does not trigger it. I can't get our web application to either.
NS> Is it worth checking in? Maybe someone can come up with a
NS> better trick.
I'm not sure what your trick is, since you've only described it as a
"decref counter." It may not be what I was thinking of. Regardless
of whether it is, my idea may not be any good either.
I was imagining a scheme like this: Count increfs and decrefs. Set
two thresholds. A collection occurs when both thresholds are
exceeded. Perhaps 100 decrefs and 1000 increfs.
NS> Note that we must take into account generations as well. If
NS> threshold0 is low then there are lots of quick collections.
NS> Setting it larger does not help too much as new objects will
NS> eventually be examined (unless they are destroyed before the
NS> next collection).
How does this come into play in the benchmark in question? It seems
like we should have gotten a lot of quick collections, but it was
still quite slow.