> Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it i

> Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it is so heavily used for so many things. To paraphrase jwz, the JVM is big because your needs are big. I did say that JVM is the way it is due to its wide spared use and that GO team is setting expectations of GC overhead. There are too many java programmers without any thought of GC. > That statement lacks too much context to mean anything. Most JVM GC pauses are young gen only and those take virtually no time at all, 10ms would be very high for such a collection. Other pauses can be just a few milliseconds as long as you don't actually run out of memory (this will force a full stop the world collection), but it tends to depend on how much free RAM you have and the sizes of the heaps, etc. > State of the art collectors like Azul's and Shenandoah aim to collect heaps that are hundreds of gigabytes with pause times in the few milliseconds or less range. I was expecting that anyone who knows generational GC already knows how fast most young gen GC pauses are. When you talk about pause time goals you talk about worst case times which is old gen GC. And for a big and complex heap getting to 10ms pause time is not at all easy in my limited experience. CMS and lots of memory helps but it is still no way trivial. Azul's is completely different and Shenandoah has big expectations and some nice design but only time will tell if the theories works well in practice (I do hope so). You commented on G1 in another place and while I was highly anticipating G1 in my own latency sensitive server G1 performed much worse than CMS. I didn't try to tune it much but the point remains its not as easy as just use G1, set the pause time goals and you are done. All GC (in JVM world at least) seem to start with good theories than you find it doesn't work for all kinds of realistic usage pattern and adjust. G1 had to change a lot of their assumptions once it met the real world (from the JavaOne talks of Oracle people). > I don't know why Go would be more allocation friendly than Java, but I'm not a Go expert. What features are you thinking of? I'm purely a Java guy but I think someone already gave some answer.