To me it seems pretty misleading to publish a benchmark with a language setting that basically cannot be used in real world applications. Makes the whole benchmark pretty much pointless except as a game.

It’s not necessary a “language setting” — a Java “ExecutorService” is an abstraction which allows one to dispatch futures / async jobs. In this case, the DirectExecutor is an implementation of this service that, doesn’t do anything async at all, avoiding context switches and all other overhead that comes with it.

If anything, to me it’s a clear example of why benchmarks like these are silly as they benchmark very uninteresting aspects that typically are never real world bottlenecks.

That's specifically the purpose of the benchmarking right ? to be misleading and get attention. I guess this benchmark achieved that.

Java subs are celebrating it like they won a war. Java is a great language and will remain one of the top languages in the near future. But these silly benchmarks don't serve any purpose.

I am expecting to see this benchmark thrown around a lot from now on any language discussion. Whoever is doing these benchmarks should be more responsible and sensible.

I'm not primarily a Java developer and this use of "blocking" is very confusing to me. Outside of the Java world whether something is blocking or asynchronous is a property of the API, and usually obvious from the method signature (e.g. if it returns a future or accepts a callback it's asynchronous; if it has a timeout it's blocking, etc.). For example Go unary gRPC is certainly "blocking" as far as any code a user writes cares - both the server start/stop and the individual calls are completely synchronous on their goroutines. And this is also how the term is used in the Java gRPC documentation.

Instead here it seems to mean something more like "is capable of deadlocking if a thread pool is exhausted" or therefore roughly equivalent to "not lock-free". Is that correct? (But then the comments about `volatile` confuse me more - can you deadlock a thread with purely `volatile` access if your platform doesn't natively support it? That seems like a large failing of the JVM.)

Can I upvote this a few times?