As usual, Smalltalk has already had this for years. (Both incremental and generational could run concurrently, configurable by the programmer. And no one cared. It was no big deal. Java gets it, it's news. Like about 100 other things. Word to the wise: Smalltalk is a bellweather for Java!)
The problem isn't the two orders of magnitude difference in population. It's why more of the Java community hasn't clued into this bellweather relationship. This would make developments in the Smalltalk world also news in the Java world. This pattern has been in place for over a decade now, why so little clue?
WTF are you talking about? Smalltalk is regularly and routinely brought up as a major influence on Java, and a ton of the Java papers directly cite Smalltalk research. Are you serious?
The phrase "incremental and generational could run concurrently" is completely meaningless. "Incremental" implies "not concurrent", and "generational" is a feature you add so that "incremental" or "concurrent" collection can be done very quickly over a smaller reference graph.
I may have got the terminology wrong, but I was a part of the Smalltalk group when Visualworks was pushing out a VM enabling both generational and incremental GC -- with both in operation on the same image.
I'm surprised, then, that you would so flippantly dismiss this with such an ignorant statement. Java has had a generational gc for the majority of its existence, since version 1.2 (released '98, only 2 years after Oak dropped), which, of course, implies that its had an incremental or concurrent collector (or more appropriately, collectors - you can pick which one you want to use in Java-land, too) since at least then, as well.
If you had clicked past the pretty terrible article title and actually read up on this collector, you'd realize that isn't the "generational" or "incremental" that's important, it's the "compacting" part that, along with some implementation details, cuts down on management overhead and reduces fragmentation, and the effort to provide soft real-time behavior, along with some cool configuration parameters where you can specify how much of a given timeslice you're willing to give up for gc.
There are a lot of things that you can be critical of Java for, but slouching on the vm isn't really one of them.
Right, so this isn't news in that it's new technology. It's news in that the JVM is becoming a better platform & catching up, technologically, to where other languages have been for years.
One nice thing about this is that all JVM languages get this improvement. Will it allow for more functional programming to be done? I wonder what it'll do for non-Java performance - say for Scala, JRuby, Clojure, etc.
You don't have to wonder, the paper (http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf) tells you. It will drop throughput a little bit, but much less than you'd maybe think given that you're gaining more predictable pauses that you'll actually be able to configure yourself.
Also, be more skeptical of what stcredzero is saying. He's dismissing this out of hand, but its pretty clear he doesn't really know what he's talking about. This actually is a cool new technology. Java has had what he's complaining about for years, the vast majority of its existence, in fact.
