What's the problem? They didn't patent gc in general. And pauseless gc seems like one of those things everybody wants, so if it really were trivial and obvious, it would have been invented by now. The fact it took this long implies that their invention is, in fact, novel.
Indeed, it's been a Holy Grail since I showed up on the scene in 1979. I think I stopped using Lisp Machines before generational garbage collection was added to the ones I was using, which made them "less pauseless", but Azul's entire approach is novel:
Instead of deferring the hard cases as long as you can (e.g. in generational GCs doing collections beyond the nursery) at which point they're likely to be painful, concentrate on the hard cases first and foremost. Get those right and everything else falls into place. Here's their CTO discussing that in a short interview: http://www.artima.com/lejava/articles/azul_pauseless_gc.html
A relevant quote:
[...] Our collector really does the only hard thing in garbage collection, but it does it all the time. It compacts the heap all the time and moves objects all the time, but it does it concurrently without stopping the application. That's the unique trick in it, I'd say, a trick that current commercial collectors in Java SE just don't do.
Pretty much every collector out there today will take the approach of trying to find all the efficient things to do without moving objects around, and delaying the moving of objects around—or at least the old objects around—as much as possible. If you eventually end up having to move the objects around because you've fragmented the heap and you have to compact memory, then you pause to do that. That's the big, bad pause everybody sees when you see a full GC pause even on a mostly concurrent collector. They're mostly concurrent because eventually they have to compact the heap. It's unavoidable.
