Queue cleanup

[Paul Rubin]

Hans Mulder <hansmu at xs4all.nl> writes:
> 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.

Quibble: parallel GC just means any GC that runs in multiple threads
simultaneously.  A GC that guarantees no pauses (more technically,
specifies a constant such that any GC pause is guaranteed to be shorter
than the constant) is called a "real time" GC, and real-time GC's are
usually single threaded.  Parallel real-time GC's were once sort of a
holy grail, though workable ones have been implemented.  GHC for example
currently uses a GC that is parallel (runs on multiple cores for speed)
but is not real-time (there can be a pause), and I think the Sun JVM is
the same way.

These days I think the GC pause issue is overrated except for real-time
control applications.  GC's no longer frequently make the program freeze
up for seconds at a time or anything like that.  It was worse in the old
days when CPU's were slower and memory was scarcer.  Serious GC's are
usually generational, with "minor" GC's taking microseconds and less
frequent "major" GC's taking fractions of a second.  So in an
interactive program or animation on your desktop you might notice a
little hiccup once in a while.  For something like a web server an
occasional slight variation in response time could easily be random
network delays and so forth.