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 :)
One of the largest problems with the sun-jvm GC implementations is they have global pause times to rewrite pointers. This is (in part) because there is no read barrier, and thus all threads must be paused to be 'fixed' after object moves.
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?
Sure. The MPS approach that's deployed commercially is to use an unfashionable hardware read barrier to amortize the cost of the pointer rewrite, allowing the heap to be compacted incrementally. There's nothing that takes minutes or even seconds -- the cost is spread through the entire execution. In some sense, all this can take "minutes" of real time, but not at the cost of stopping the program doing stuff. The MPS design has always been to spread the cost evenly, not push it into a cataclysmic event in the future.
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
I am not really sure the current state of things, but to "get real" I feel any GC needs to be able to handle:
- 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!
I think we'd need a more careful definition of "handle" there!
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.
The 2002 ISMM paper on MPS says that there is a global pause. As usual, it may be fine for small heaps and allocation rates, but eventually it will become a problem.
There is currently a "global pause" to scan thread registers and stacks at "flip", but that's all. Is that what you meant?
Since we're just moving our commercial clients onto 64-bit, we don't have experience except up to the 4GB limit (or 3GB in old Windows) which they approach regularly. We're still waiting for it to become a problem. I may have a different opinion in a year.
One of my short term goals is just to get some measurements together to publish. Watch this space, and sorry that they aren't here yet.
