Observation #1: stop-the-world garbage collection is a thorn in the side of latency-sensitive applications.
Observation #2: we will very soon have more cores than we know what to do with.
Prediction: fully concurrent garbage collection is the future of automatic memory management. I’m talking garbage collectors that run in other threads and clean up after me without ever stopping me in the middle of what I’m doing.
It will almost certainly be more expensive in terms of total CPU time, and probably can’t be as aggressive in terms of what it can reclaim at any point in time, but for most applications the latency guarantees will far outweigh.
Discuss.
Cliff Click just had a post about this (and other multi-core) issue and he seems to agree: http://blogs.azulsystems.com/cliff/2008/04/we-dont-know-ho.html
I personally agree, even though I’m currently programming well outside of the GCed world right now. The sheer volume of cores that we have coming down the various product pipelines is going to be hard to keep up with and I think we’ll see more of these "dedicated core" tasks as the core count exceeds the parallelism of most code.
I think that the software industry is behind the eight ball on this one. Writing parallel software that is correct is challenging yet usually manageable. Writing parallel software that is correct _and scales as the core count_ is very difficult.
Thanks for the reference Dave. Cliff points out that JITing should also happen in a separate thread — this seems like an obvious corollary.
Sun has a version of java that has Real-Time characteristics. James Gosling spoke about this and was pretty excited about it when he came and visited Palantir.
real time java faq
java RT GC guide
Parallel garbage collection isn’t really new and there is a “low-pause” collector for modern versions of java.
5.0 gc tuning
It’s true, I’m officially a java programmer now
I believe that Mac OS X has garbage collection that runs in its own thread starting with OS X 1.5.