|
|
|
|
Back to newsletter 156 contents
Before I launch into where the G1 collector is going, I've got a couple of useful tidbits for you. First off, a colleague asked me for a list of Java performance books, and I realised I no longer had an up to date one, so I've published that over on fasterj.com. And secondly some of you may recall Excelsior last year selling their JET product for a ridiculously low amount to raise money for charity (very successfully), and they're doing that once again this year - and excellent offer for you and you're giving to charity at the same time.
So, back to G1. The G1 garbage collector is now the Oracle strategic garbage collector. That means that most garbage collection development effort will go into G1 - the other collectors will only really be bug-fixed, and they're unlikely to be improved much apart from for critical issues: where something is clearly causing performance problems for a significant percent of JVMs or for important Oracle customers.
But the G1 GC is not yet anywhere near ready to replace the use cases that the other collectors handle more efficiently, so this is a multi-year replacement strategy. As G1 gradually improves, the other garbage collectors will be retired. This can't start, of course, until G1 becomes the default collector, so keep an eye out for the default GC in any release.
The current priority for G1 is to roll in some concurrency - it's currently completely stop-the-world, which means that it can't compete with the CMS collector; it first needs concurrency added and then tuned and all those edge cases that we know exist in the hugely diverse Java world are attacked. Concurrency in G1 is due to be rolled in over the coming year. I'd expect that by mid-2014 we'll be seeing some segments of G1 concurrent, and by mid-2015 G1 will be capable of being as concurrent as CMS is now, perhaps even more so as G1 can defragment during GC with lower overhead than CMS - CMS's fragmentation is its major achilles heel.
In the same timescale, though with different priority, Oracle are targeting providing deterministic low latency pauses in G1 - aiming for consistent deterministic pauses in the 10ms range. That's targeted at competing with Azul's Zing and IBM's Real Time garbage collectors. It's likely to be a non-free feature from Oracle (just like those other two), so if you need deterministic low latency pauses in your applications, it's time to start budgeting for it. I've seen companies now make this analysis a few times, especially in trading apps: the business wants pause times decreased as it impacts profits; the cost of putting in place a low-pause JVM is considered; it turns out that this would be quite expensive to roll out generically so cost-benefit analysis is applied; finally it's realised that only a few critical JVMs actually need deterministic low-pauses that justify spending money on them. And Oracle wants a slice of that market.
Now on to all our usual links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 156 contents
