8 ms·

Reference counting is a different model. Many papers have explored the differences and similarities, and your comment leaves so much out that it cannot even be

Reference counting is a different model. Many papers have explored the differences and similarities, and your comment leaves so much out that it cannot even be said to be true or false. I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions.

EGreg 1mo ago
It doesn't leave anything relevant out. 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.
- thomashabets2 1mo ago
  I understood your first comment without expanding on it like this. You also don't need to explain what reference counting is. > 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.
  - pjmlp 1mo ago
    Same can be said for bad algorithms and data structures, it isn't hard to make slow C when one doesn't know their stuff.
- pjmlp 1mo ago
  Lisp pionered GC, and all its flavours, followed by CLU, Smalltalk, Cedar, BASIC and all its flavours, Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, xBase/Clipper, Standard ML, Caml Light, Objective Caml (now OCaml), Miranda, Haskell,... Long before Java was even an idea.
JackSlateur 1mo ago
GC, zero instructions: that's funny; JVM used to "stop to world" to process that zero instructions;
- thomashabets2 1mo ago
  I was explicitly talking about exactly one very specific part a way to implement GC. It was very clear that I was not talking about the active parts of the garbage collection. It's really cheap to produce garbage.
Someone 1mo ago
> I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions 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.
- thomashabets2 1mo ago
  Yup. I don't have to like GC to name a benefit of it. Which is good, because I don't like GC. 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-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
  - pjmlp 1mo ago
    Which GC? Java is like C and C++, plenty of implementations to chose from, including reference counted implementations in the past [0], arenas and real time GC for embedded deployments [1]. People love to complain about Java without understanding the ecosystem. [0] - https://www.cs.utexas.edu/~mckinley/papers/rcix-oopsla-2013.pdf https://www.cs.utexas.edu/~mckinley/papers/rcix-oopsla-2013.... [1] - PTC and Aicas
    - thomashabets2 1mo ago
      I don't claim to be an expert on it, but I'm not uninformed either. Yes, I'm aware of many implementations and variations. With various talks from vendors that rant about "a mostly-pauseless GC is one that sometimes pauses!! Ours is a pauseless compacting GC". 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.

EGreg 1mo ago

It doesn't leave anything relevant out. 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.

thomashabets2 1mo ago
I understood your first comment without expanding on it like this. You also don't need to explain what reference counting is. > 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.
- pjmlp 1mo ago
  Same can be said for bad algorithms and data structures, it isn't hard to make slow C when one doesn't know their stuff.
pjmlp 1mo ago
Lisp pionered GC, and all its flavours, followed by CLU, Smalltalk, Cedar, BASIC and all its flavours, Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, xBase/Clipper, Standard ML, Caml Light, Objective Caml (now OCaml), Miranda, Haskell,... Long before Java was even an idea.

JackSlateur 1mo ago

GC, zero instructions: that's funny; JVM used to "stop to world" to process that zero instructions;

thomashabets2 1mo ago
I was explicitly talking about exactly one very specific part a way to implement GC. It was very clear that I was not talking about the active parts of the garbage collection. It's really cheap to produce garbage.

Someone 1mo ago

> I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions 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.

thomashabets2 1mo ago
Yup. I don't have to like GC to name a benefit of it. Which is good, because I don't like GC. 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-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
- pjmlp 1mo ago
  Which GC? Java is like C and C++, plenty of implementations to chose from, including reference counted implementations in the past [0], arenas and real time GC for embedded deployments [1]. People love to complain about Java without understanding the ecosystem. [0] - https://www.cs.utexas.edu/~mckinley/papers/rcix-oopsla-2013.pdf https://www.cs.utexas.edu/~mckinley/papers/rcix-oopsla-2013.... [1] - PTC and Aicas
  - thomashabets2 1mo ago
    I don't claim to be an expert on it, but I'm not uninformed either. Yes, I'm aware of many implementations and variations. With various talks from vendors that rant about "a mostly-pauseless GC is one that sometimes pauses!! Ours is a pauseless compacting GC". 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.