I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions.
Java pioneered this garbage collection stuff because you had cycles of references. You don't need to have cycles. WeakRef is a much better thing now. All you need is reference counting, and you don't need any garbage collection at all. When the reference count reaches 0, you destroy the object and free up its memory. It's far more predictable than GC, too.
And GC isn't "the fastest" to free objects, it has to walk a graph. The fastest is actually arena allocation and then just dropping the whole thing. But that's exactly what owning an entire container of objects can do. If you have a doubly linked list, for example, A[n] -> A[n+1] but also A[n+1] -> A[n] but neither of those should be a strong reference to prevent reclaiming. Instead, the container of that doubly linked list should be the one having a strong reference to its items.
> GC isn't "the fastest" to free objects, it has to walk a graph.
No, you don't inherently need to. And what I said is that it's super duper fast to produce garbage. I did not say that actually freeing the underlying memory, or any other cleanup, was fast.
I'm not even arguing for GCs, here. I even think GC languages tend to become tech debt generators, as garbage is not addressed until it's a really complex problem with no good solutions.
Long before Java was even an idea.
True, but reference counting or free need not be far behind. They can append the pointer being freed to a per-thread list (⇒ no locking needed) that a separate thread that does the actual freeing periodically claims and then iterates over to actually free the objects.
Disadvantage is that memory usage goes up a bit because the actual freeing is delayed, but that (likely) is less so than with a garbage collector.
Java is a particularly good example of GC being bad[1], but I've also found it to be a tech debt generator in Go.
[1] A rant, which touches on GC stuff: https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
People love to complain about Java without understanding the ecosystem.
[0] - https://www.cs.utexas.edu/~mckinley/papers/rcix-oopsla-2013....
[1] - PTC and Aicas
But per my linked blog post (that you did read?) I do go into Java language problems that make GC impact worse.
The care and feeding of the Java runtime environment, entirely a self inflicted problem, that goes from selecting one and tuning ALL its parameters, kind of proves my point. It's not just knobs, but whole runtime environments. If there had been "a best one" with no knobs, that "just works", then fine. But there isn't.
Ignores that Java had escape analysis years before Go happened, granted the quality depends on which JVM is actually used, e.g. GraalVM is better than OpenJDK, and there are others to chose from.
Ironically Go designers got educated why GC knobs are relevant, and why a single GC doesn't solve all use cases.
And it doesn't need an advanced GC, so Green Tea rewrite was wasted work?
You can do off heap allocation in Java with Unsafe, JNI, ByteBuffers, and more recently Panama. This not taking into account the APIs provided by real time Java specification.
Finally with Valhalla design now being merged into the language (Java 28+) we get explicit value types, while Go still needs to rely on compiler warnings for failed escape analysis.
And the remaining Java rant could be further deconstructed.
However your blog clearly points out where you stand in regards to Java, so maybe some unwillingness to learn the ecosystem was part of it.
Yeah, because I don't think that matters. I do assume that Java has most of the state of the art GC work applied to it. Partly because it produces more garbage because of language decisions.
> And it doesn't need an advanced GC, so Green Tea rewrite was wasted work?
One of the problems with GC is that it means forever working to come up with the "sufficiently smart GC". It was Java's original sin wrt memory, and why it did not mind producing so much garbage.
But in my opinion Java has illustrated very well that there's no end to pursuit of the perfect GC. And being runtime behavior I find it a worse one-way door choice than Rust trying to find the perfect borrow checker.
But no, it's not wasted work. Just like with Java improving GC and allowing programmers to produce less garbage (I shall resist making a pun here) will save many dollars of electricity, battery life, and human waiting time.
> However your blog clearly points out where you stand in regards to Java, so maybe some unwillingness to learn the ecosystem was part of it.
You could say that. You could also say that I won't aim to become a connoisseur of the many flavors of poop that Java is working on. The point of my is that it's clear from history and evidence that Java is poop, so finding the best tasting poop is not really interesting, nor in going in to too many details about the nutmeg aroma and polished shine a particular ball of next gen GC delivers.
Life's too short to continue tasting what is already known to be poop.
It was very clear that I was not talking about the active parts of the garbage collection.
It's really cheap to produce garbage.