Hacker News Reader

Comment by arielweisberg | Hacker News Reader

Still no solution for the GC fragmentation and pauses? Arbitrarily large heaps and data structures?

They are going to improve lock performance, but do nothing to help people avoid locking like lightweight threads. Not waking up a thread and not locking is faster...

It's weird how so many software projects completely lose sight of the fundamentals.

I know I am biased due to how I use Java. I care very little for syntax and syntactic sugar. Reading and typing speed is not a problem for me. Get stuff done on time is and working around these shortcomings eats up my time.

View on HN

If you want to rid yourself of GC problems, go buy Azul's Zing JVM. It works like magic.

(disclosure: I'm a very happy customer of theirs)

Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction.

The reality is that you have to build software that works on the Oracle JVM.

ah, understood. have you been tracking shenandoah? http://openjdk.java.net/jeps/189

I have heard of it but haven't read up. I think it's great that someone is stepping up to address the issue. Interesting that both the authors listed in the JEP work for Red Hat.

Shenandoah is unlikely to see the light of production release until Java 10. I ran a very early piece on this - http://www.jclarity.com/2014/03/12/shenandoah-experiment-1-w... - really glad to see more experiments in this space. I'll add that G1 from Java 8u5 onwards is pretty darn good out of the box.

If Zing performs as well as you say, why have neither Google nor Oracle purchased it? I imagine that even Microsoft would be interested because they could try adapting it to .NET.

It seems that they published a description of how their algorithm works: http://www.azulsystems.com/sites/default/files/images/c4_pap... My cursory read of the paper suggests that it increases memory requirements by a factor of 100 over the working set and if it cannot get that much memory, the garbage collection will run slower than a standard garbage collector.

What particularly is your issue around GC fragmentation? I ask because I had issues previously, but it was "solved" by moving to the G1 GC, I didn't know if you have considered the same.

G1 still fragments and does long compacting stop the world GCs. G1 pause times are still too long. G1 still doesn't have enough throughput.

It's bad enough that people who care aren't using G1 yet. They still use CMS and small heaps and are careful to prevent promotion and fragmentation.

You basically end up benefiting from GC for short lived allocations, but pay dearly for using Java when managing state the collector can't handle.

I have not closely reviewed this benchmark but this was one person's experience http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-jav...

We had to switch from CMS to G1 when moving to JDK8 for reasons yet unknown, other than CMS used considerably more than CPU it had in JDK7. Fortunately, it's not a service that can't tolerate 500ms pauses here and there.

I'd be cautious of a 2013 report. G1 has had significant work put into it over the past year and is much improved in its latest incarnations. We've seen best results with Java 8u5+ (Disclaimer: I run a company that sells a GC analysis tool).

if such a thing is so staggeringly important, why in the world are you on the jvm? use c++ or something, eh? right tools yadda yadda.

Reply on news.ycombinator.com