Hi all,
I'd like to finally make the shift to GenImmix as our production
collector. See rationale below.
My plan is to make the switch in the next 24 hrs unless I hear
objections. I suggest we revisit the decision in a week, having let
things run for a while.
It is trivial to back out, so if things are looking ugly and I'm
unresponsive, you should feel free to pull the plug.
Cheers,
--Steve
Rationale:
1. GenImmix is now as stable as production (as far as we can tell with
the tests we're currently running---we'll have a better picture once
it is run as production).
2. GenImmix provides a modest performance advantage over GenMS
(currently used by production) in large heaps and can be significantly
faster in small heaps. It improves both mutator (a little) and GC
(somewhat more).
. Here are numbers comparing GenImmix and production on a 3 X heap on
a Core 2 Quad:
http://cs.anu.edu.au/~Steve.Blackburn/private/results/immix-production-2009/c2q/ (with links for total time ("time"), mutator and gc times).
(Note that there's a small bug in my scripts which doesn't deal
gracefully with gc time for mpegaudio, where GenImmix does zero GCs at
this heap size, while production does a non-zero amount).
3. GenImmix is a bit more algorithmically robust than GenMS since it
includes defragmentation. Whether or not the actual implementation
is currently more robust is something that only more aggressive
testing will tell.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core