The whole section on how GCs work is far from accurate. It only describes how one GC, CMS, works or worked because it had been removed. The permanent generation does not exist anymore since Java 8, etc

And i'm far from being an expert in GCs, but the basics are just wrong.

Maybe they have to use some kind of legacy JVM library that doesn't work on Java 8? It looks like they're a GoLang shop, so I'm not sure why we'd assume their Java stuff is representative of anything other than what they have to do because some useful JVM library for mapping or something needs to be supported.

The problem is that Java 7 is 10 years old, it means that you are missing 10 years of optimization. For GCs that's a lot.

GCs before ~2010 have been optimized for throughput more than for latency. Since then, you can choose.

Since 10 years, G1 let you set your maximum pause time and you get a huge warning if it miss that target, ZGC or Shenandoah are from the beginning latency first, throughput second.

I last tuned Java 6 in about ~2009 and I was a bit shocked at how familiar most of this article sounded...

Like your handle, too.

Any advise on good / recent sources of information about the various GC algorithm in the recent JVM ?

It is Hadoop that requires (mostly) Java 8 and Java 11 (runtime only). https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Ja...

That's for Hadoop 3 - Uber is on CDH 5 last I read, which has min support for Java 7 and it sounds like that's what they're using if the CMS GC was being used (unless it just happened to work better for them in Java 8+).

Yikes. Fortunately Java is a supported language at Uber, though some teams are more serious about it than others. Scala is also accepted because of Spark.

I guess I misunderstood things then. It's difficult to reconcile why they'd be using a legacy version of Java that required these specific GC tunings if they weren't forced to use it because of libraries that couldn't be replicated or replaced in GoLang. Sounds like it's a much bigger mess there than what I had assumed (I guess I was giving them too much of the benefit of the doubt).

Well, at least they take the cake when it comes to running CMS with the largest heap size?

It is also quite ironic that they paid for Zing C4, and then came up with "P90 average RPC queue time" as the metric, ignoring Gil Tene's wisdom that you should never average percentiles.

Another problematic statement is this:

> which in turn decreases request latency and increases throughput

Gil Tene wants you to measure p99.99 or pmax, so that you will pay for Zing C4 to get lower tail latency, while sacrificing some throughput. If you end up getting both lower tail latency and more throughput, then something is already very wrong with the existing setup (i.e. the full GC).