[BinaryRage]

The figure is about the overall improvement, not sure why that reads increase.

On JDK 8 we are using G1 for our modern application stack, and we saw a reduction in CPU utilisation with the upgrade with few exceptions (saw what I believe is our first regression today: a busy wait in ForkJoinPool with parallel streams; fixed in 19 and later it seems).

G1 has seen the greatest improvement from 8 to 17 compared to its counterparts, and you also see reduced allocation rates due to compact strings (20-30%), so that reduces GC total time.

It's a virtuous cycle for the GRPC services doing the heavy lifting: reduced pauses means reduced tail latencies, fewer server cancellations and client hedging and retries. So improvements to application throughput reduce RPS, and further reduce required capacity over and above the CPU utilisation reduction due to efficiency improvements.

JDK 21 is a much more modest improvement upgrading from 17, perhaps 3%. Virtual threads are incredibly impressive work, and despite having an already highly asynchronous/non-blocking stack, expect to see many benefits. Generational ZGC is fantastic, but losing compressed oops (it requires 64-bit pointers) is about a 20% memory penalty. Haven't yet done a head to head with Genshen. We already have some JDK 21 in production, including a very large DGS service.

[pron]

> G1 has seen the greatest improvement from 8 to 17

Yep. G1 in newer JDKs is very different from G1 in JDK 8, but Parallel GC has also seen very significant improvements: https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html

[algo_trader]

> Virtual threads are incredibly impressive work,

Do you have an (un)informed opinion on minimum task sizes for the green threads?

My interest is re-factoring java code to reduce total wall clock time, on large compute with plenty of memory/cache.