haxen

> I mean that they don't require any explicit yields.

So in this sense, are Kotlin coroutines also non-cooperative? They don't explicitly yield, but do have a mandatory API to use for "blocking" calls.

"Virtual threads" are fibers? When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber?

All the modern GCs scan the heap concurrently, the hardest problem is scanning the GC roots in the call stack. ZGC is currently implementing concurrent stack scanning.

We use the same technique of cooperative multithreading under any name, but without the low-level support to be able to write plain sequential Java code. However, even though that changes our internal programming model, the behavior with respect to native threads, interactions with the OS scheduler, CPU caches, etc., should be identical.

We did measure on Shenandoah as well, it helped but not enough to be within 10 ms. Since this post is about Hazelcast Jet getting the best latency, we didn't report that.

An ahead-of-time compiler doesn't have the advantage of the call profile of polymorphic call sites. The JIT compiler has much more inlining opportunities, and in some cases this results in better performance.

Also, there are cases where manual memory management, which usually boils down to reference counting, has great overheads where a GC-managed runtime has no overhead at all. They involve repeatedly building up and then discarding large data structures. GC algorithms simply don't see the dead objects, whereas refcount-based management must explicitly free the memory of each object.

If you ever try to write a bash script that calls a Java program in a tight loop, you'll know the limitations of a fat interpreting runtime with JIT compilation. Another relevant use case is the Stateless Lambda server-side architecture.

Keep in mind that it's not fundamental. Generational GCs just make a bet that you can save a lot of effort by segregating the objects by age. In almost all Java workloads there's plenty of short-lived objects, and a generational GC takes care of them at an especially low cost. The price to pay for that is pretty low, basically it's the overhead of card marking (a write barrier is needed) and subsequent partial scanning of the Old Generation if there are many references from old to new objects.

Only very specialized workloads won't create much short-lived objects, and for those cases there are alternative non-generational GCs on the JVM (Z, Shenandoah).

In the case of Hazelcast Jet and similar products, loads of young garbage are unavoidable because it comes from the data streaming through the pipeline. A generational GC should in principle get a great head start in this kind of workload, and our benchmarks have confirmed it.

The worst things happen when value objects are stuck on the heap for a while and then turn into garbage when the value is updated. Escape Analysis doesn't help there, only a good GC can help.

Nothing special to see here, run-of-the-mill Tesla FUD. All the discussed events were forecasted before this year began. The delivery pipelines to anywhere outside the US were being fired up for the first time; naturally the number of units in-flight rose and deliveries temporarily sank. Sales, however did not sink at all and there are still almost no cars that were produced, but not yet sold ("inventory" cars).

Yes, as I wrote the previous comment that stood out as the "obvious fix". However, there are many other hurdles to this model, like handling all the logistics behind the batteries: charging them up, shipping them around as demand requires, manning each station because the physical process of battery swapping is not 100% reliable, and so on. This would cause the costs to rise and there would be far fewer such stations compared to supercharging stations. And people just don't have a problem with stopping for a 20-minute charge.

Then there's the huge showstopper issue of the tragedy of the commons. People would lose the incentive to care for their batteries, they'd charge them to 100%, wouldn't care about their temperature, would do all kinds of abuse and then go for a replacement. This goes back to the initial argument of batteries not being as fungible as, say, gas.

Comparison with smartphones doesn't stand: swapping a phone battery means shelling out cash for a brand new one, done once in several years. Quick-swapping the EV battery means getting another, used one, in a questionable state. Car owners aren't willing to pay dear cash for their own battery, treat it carefully, only to hand it over to a stranger. Batteries, due to their delicate makeup, just aren't a fungible commodity like that.