Queue cleanup

[Hans Mulder]

Steven D'Aprano wrote:
> On Sat, 28 Aug 2010 00:33:10 -0700, Paul Rubin wrote:

>> If you drop the last reference
>> to a complex structure, it could take quite a long time to free all the
>> components.  By contrast there are provably real-time tracing gc
>> schemes, including some parallelizeable ones.
> 
> I could be wrong, but how can they not be subject to the same performance 
> issue? If you have twenty thousand components that all have to be freed, 
> they all have to be freed whether you do it when the last reference is 
> cleared, or six seconds later when the gc does a sweep.

Parallelizable garbage collectors have performance issues, but they're
not the same issues as mark&sweep collectors have.  Parallelizable GCs
break up their work in a zillion little pieces and allow the VM to do
some real work after each piece.  They won't free your twenty thousand
components all in one go and you won't have that embarrassing pause.

Parallelizable garbage collectors require some careful coordination
between the GC and the VM.  This takes CPU time, so on the whole they're
slower than traditional garbage collectors.  So instead of unpredictable
embarrassing pauses, you have a VM that's consistently slow.
For some applications consistency is more important than raw speed and
for these applications parallelizeable GCs are an improvement.

HTH,

-- HansM