Hacker News new | comments | show | ask | jobs | submit login
Brief comparison of Java 7 HotSpot Garbage Collectors (omsn.de)
37 points by omsn on Feb 24, 2013 | hide | past | web | favorite | 9 comments



> CMS: Best for: don't use this, use G1 instead

[Citation needed]

As of a couple months ago, the experts I polled considered G1 bleeding edge.


Yea I would love to see any kind of data, graphs, explanations, war stories, etc on this. We've invested a lot of manhours in tuning our CMS GC settings, so I need more than "its the latest" to justify a few weeks of testing & rollout.


Anecdotally, I've found the CMS is still a bit better (10-15% faster) than the newer G1, but the G1 has some features which make me inclined to use it. The G1 will return memory to the system, which I have never observed the CMS do, despite having tons of unused memory in my Java applications.


I also found the CMS collector to be both faster and generating latency numbers with less variance for our application. But, I last checked a good year ago and things might have changed since then.


http://docs.oracle.com/javase/7/docs/technotes/guides/vm/G1.... - at the end it says "G1 is planned as the long term replacement for the Concurrent Mark-Sweep Collector (CMS). Comparing G1 with CMS, there are differences that make G1 a better solution." - as G1 shipped with Java 7 I think it's stable, otherwise they probably would have waited until Java 8 imho.


"Stable" != "high performing", especially under all possible allocation & garbage generation patterns.


In my experience, G1 basically doesn't yet work well under high garbage high load scenarios. Its responsiveness was worse than untuned CMS, and significantly worse than tuned CMS.

I'd love for it to work since long pauses are the bane of any garbage collected server :)


That has been my experience too. At least it doesn't seg-fault all the time any more.


CMS or G1 for my application are similar in performance. The killer is still a full stop the world pause when the heap is totally filled. Other wise G1 for beta.sparql.uniprot.org performs slightly better. On average lower memory utilisation and faster collection times. This is with a 30-100 GB heap on a 64 core machine.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: