Hans Mulder <han...@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. -- http://mail.python.org/mailman/listinfo/python-list
