I can't give you figures right now, but the reason we have commercial clients for the MPS is that we have extremely low pause times. Side-by-side comparisons are expensive to arrange. I'm working on that :)
Additionally with CMS, there is global heap fragmentation and recompaction which can take literally minutes on a large (8gb+) heap or slow machine.
Setting aside exact figures, can you comment on the above challenges and issues?
That said, we have an abstract framework that could be made to work in other ways, depending on requirements. It wouldn't be much work to hook in a write-barrier-only pool class, etc. etc. and have it co-operate. However, most of the development effort so far has gone on the read barrier approach.
As to how this effects overall run-time, well, that's where we'd have to arrange a side-by-side comparison, and make sure it included one of those compactions :P
- multicore/multithreaded - heap sizes of 20-200GB and larger ideally
Think about it this way... We have the same goal, of diminishing the use of manually allocated ram to the smallest possible place. Think of the GC vs malloc as compilers vs assembly language. Assembly has it's place, but it's no longer because compilers cannot generate efficient object code in a vast number of circumstances. Lets do the same for GC!
And we're definitely not proselytizing garbage collection here. The MPS is a framework for both manual and automatic memory management (and co-operation between the two). One of our main high performance commercial applications is all about the manual management, and for very good reasons.
But nobody should be rejecting GC out of hand, that's for sure.
For those of us too lazy to dive into the code, can you say what this read barrier is?