> for the small heap blocks typical in apps that tend to run in this space What space is that? The big applications that the JVM targets have very large worki

> for the small heap blocks typical in apps that tend to run in this space What space is that? The big applications that the JVM targets have very large working sets (hundreds of GBs or even a couple TBs). > The outrageous amount of work that's gone into two new GC ideas over the last half century has, almost exclusively, been trying to address the latency excursions inherent in trying to collect a giant heap. But that work has been successful! We're now at 1.5ms max pause with an acceptable cost to throughput. > And it's a completely manufactured problem, because refcounting (and manual allocation strategies more generally) never head it to begin with! This is just false. Ref-counted deallocation of a large data structure also introduces latency. Unless you're also controlling the allocator (which is more work), it's also not entirely deterministic. > there are a handful of workloads Those "handful of workloads" are the ones that interest those companies running on the JDK, like Google, Netflix, Apple, Twitter, Amazon and many, many others. I would agree that some use cases benefit more from manual/refcount-collection and some benefit more from tracing, but the market for tracing GCs is humongous. > It hasn't been true for 20 years (c.f. all the GC work we're discussing), and it won't be true in the next 20 years either. "We won't get there", as it were. Well, I strongly disagree, and the millions of happy JDK users will likely disagree, as well.