6 ms·

Garbage collection is useful

165 points by surprisetalk 1y ago

deleted 1y ago
[deleted]
cmrdporcupine 1y ago
Had similar epiphanies some many years ago (ugh, I'm old) when I was playing around writing a garbage collected persistent (in the 'stored on [spinny spinny] disk' sense not the FP sense of the word) programming language / runtime. This was back when it was roughly infeasible to be holding large "worlds" of objects purely in-memory on machines of the style of the time, so intelligently paging objects in and out was imperative. (Aside, I think with the recent doubling... tripling of RAM prices this area of thinking is now again more imperative)... In any case, if one is doing GC in such a language, a full tracing collector (whether copying or mark & sweep) is madness, as to find live references means walking nearly the entire heap including the portions living in secondary storage, and now you're in a world of pain. In this case, an intelligent cycle collecting garbage collector in the Bacon style was the answer. You keep in in-memory table of reference counts, and you only trace when you hit cycles. [and hopefully design your language semantics to discourage cycles]
- nxobject 1y ago
  I’m curious - did fragmentation end up being a significant issue, whether in memory or offloaded?
  - cmrdporcupine 1y ago
    I never got far enough to push that into a production system but I suspect it would have, yes. I can see a periodic compacting phase could be useful in a system like that. In the DB world there's good research around similar topics. e.g. LeanStore and Umbra -- Umbra in particular does some nice things with variable sized buffers that I believe are expected to help with fragmentation https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf
  - rurban 1y ago
    In real-world copying collectors defragmentation has about 6% time benefits. before - after. mark-sweep obviously not, as it does not defragment and also stops the world.
- lisper 1y ago
  > you only trace when you hit cycles How do you tell when you've hit a cycle? > hopefully design your language semantics to discourage cycles Why? Cyclical structures can be very useful. For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. [UPDATE] Two responses have now pointed out that this particular case can be handled with weak pointers. But then I can just point to a general graph as an example where that won't work.
  - vlovich123 1y ago
    > For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. Does it frequently need an owning reference though or would a weak reference suffice? Usually the latter situation suffices.
    - lisper 1y ago
      A fair point, but then you're still putting the burden on the programmer to figure out where a weak reference is appropriate. But then I'll just choose a different example, like a general graph.
  - zozbot234 1y ago
    > For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. That's not a true cycle, it's just a back link for which "weak" reference counts suffice. The containment relation implies that the container "owns" the object, so we don't need to worry about the case where the container might just go away without dropping its contents first. (Edit: I agree that when dealing with a truly general graph some form of tracing is the best approach. These problem domains are where tracing GC really helps.)
    - lisper 1y ago
      OK, then I'll pick a different example: a general graph.
alimw 1y ago
Is it possible that by knowing less about garbage collection in Java this person might have arrived at the same solution earlier? After all his initial construction of a tracing garbage collector was wasted effort.
- pdubroy 1y ago
  (OP here) It’s possible, but I doubt it. Perhaps the way I wrote it makes it sound like I was thinking about it as a GC problem from the beginning, but I wasn’t. It wasn’t until I started seeing it as as being like GC that (a) I realized that my naive solution was akin to tracing GC, and (b) I came up with the reference counting solution.
- weitendorf 1y ago
  If Grug worry about garbage collector, it mean Grug working on problem already solved by Sun Microsystems instead of problem Grug paid to solve. Except, if someone want to pay Grug to work on garbage collector for javascript framework, Grug put in position where Grug learns what Grug don't already know about it because it now Grug's job. So Grug understand why Sun solve problem, why problem hard, tell other Grug about isomorphisms between spanning trees. Now other Grug know more about what other Grug don't know, why other Grug not make same mistake of knowing better than Sun Microsystems either.
ClimatePaywall 1y ago
[dead]
keith_analog 1y ago
My favorite quote from Alan Perlis: “Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere.”
- summa_tech 1y ago
  Unfortunately, the symmetry provided by higher levels of your software stack is not always reflected by the lower levels. This causes your symmetry to be created as an abstraction. (Subroutines are more efficient to implement than co-routines on real hardware.) Abstractions are leaky and this, in turn, causes the superficial symmetry to merely mask the underlying asymmetry. If done exceptionally well, the only visible evidence of the leak will be substantial performance disparities between seemingly symmetric features (well done! this is unusual). If done with the normal level of software design quality, the evidence will show up as quirky behavior, imperfect symmetry, "well this one always works but the other one is not reentrant", etc.
- artemonster 1y ago
  Yes! Subroutine call is a) allocation of activation record b) switching context c) returning that combines de-alloc and switch. while coroutines have all of these concepts separated. Why not start with a powerful and general concept and optimize for that one?
  - aw1621107 1y ago
    > Why not start with a powerful and general concept and optimize for that one? As with basically everything, there are tradeoffs involved. Sometimes restrictions can be helpful for keeping things understandable, which can in turn make optimizations easier to implement. As a rather hamfisted example: completely unrestricted goto. Very general, debatably powerful, but relatively easy to use in a way that makes comprehension difficult. That same generality can also make it difficult to verify that optimizations don't change observable program semantics compared to something more restricted.
  - cryptonector 1y ago
    Because you can allocate the activation record on the heap, provide a way to reify continuations, and presto! now you have call/cc (and trivially implemented, no less)! Price paid: a) you need a GC (ok, whatever, sure, you have one), b) well, the performance hit of having to GC activation records (you don't care; others do), c) whoops, thread-safety got much harder and maybe you can't even have threads (imagine two threads executing in the same activation record at the same time!). That's a very very steep price.
kazinator 1y ago
Reference counting does not trace dead objects. Most of its activity is concerned with maintaining reference counts on live objects. When a reference count hits zero, that's when refcounting begins to be concerned with a dead object; and that part of its operation corresponds to the sweep activity in garbage collection, not to the tracing of live objects. It is not a dual to garbage collection concerned with its negative spaces; it's simply a less general (we could legitimately say lesser) garbage collection that doesn't deal with cycles on its own.
- moregrist 1y ago
  > it's simply a less general (we could legitimately say lesser) garbage collection that doesn't deal with cycles on its own. There are different implementation and performance trade-offs associated with both. I’ll focus on the two that are most meaningful to me. Reference counting can be added as a library to languages that don’t want or can’t have a precise garbage collector. If you work in C++ (or Rust), it’s a very viable way to assure that you have some measure of non-manual clean up while maintaining precise resource control. Similarly, when performance matters reference counting is essentially deterministic much easier to understand and model. In a lot of situations, garbage collection is an overall better strategy, but it’s not a strict superset, and not always the right choice.
  - kazinator 1y ago
    > There are different implementation and performance trade-offs associated with both. They are not the same because there are "semantic tradeoffs".
  - mbac32768 1y ago
    > Similarly, when performance matters reference counting is essentially deterministic much easier to understand and model. Is it? What happens if you remove that one last reference to a long chain of objects? You might unexpectedly be doing a ton of freeing and have a long pause. And free itself can be expensive.
    - 1y ago
foota 1y ago
Am I missing something? "This was the answer I needed! Rather than visiting all the live objects, I wanted to only visit the dead ones, and reference counting would let me do that. So I added a way of maintaining a reference count for all the nodes in the doc. When we produce a new document, we decrement the reference count of the old root node (it will always be 0 afterwards). So we recursively decrement the ref count of its children, and so on. This gives me exactly what I wanted — a way to find all the nodes that were not reused, without having to visit most of the nodes in the doc." I think there's a bit missing from the description here in the and so on, you would only recurse on a node when it's new refcount is zero, right (and the set of zero refcount nodes produced is exactly the set of dead nodes)? Isn't this sort of just like having a dirty flag on nodes, and then replacing dirty nodes?
- iddan 1y ago
  Which is garbage collection?
  - foota 1y ago
    Yeah, all I'm saying is I felt the description of how it worked was missing a few pieces.
agentultra 1y ago
I’ve often noted that most projects of a certain size tend to implement some form of garbage collection and allocation. Perhaps general purpose systems of these sorts aren’t suitable for specialized applications… but I don’t get the “hate” (if you can call it that) which some programmers have for GC.
- cogman10 1y ago
  As someone that likes GCs, I understand it. GCs have a lot of tradeoffs involved. It's impossible to check all boxes and that means that there's going to be something to gripe about. If you want your GC to be memory efficient you are likely trading off throughput. If you want your GC to allocate fast and avoid memory fragmentation, you are likely over-provisioning the heap. If you want to minimize CPU time in GC, you'll likely increase pause time. If you want to minimize pause time, you'll likely increase CPU time doing a GC. All these things can make someone ultimately hate a GC. However, if you want a programming language which deals with complicated memory lifetime (think concurrent datastructures) then a GC is practically paramount. It's a lot harder to correctly implement something like Java's "ConcurrentHashMap" in C++ or Rust.
- surajrmal 1y ago
  For specific use cases, it's not only more ergonomic, it can be more performant. Look at Linux kernel use of RCU. The important thing is to maintain control over the allocation strategy and lifetime of data depending on the use case for systems programming. Defaulting to a GC just removes your control which is the problem. GC itself is not problematic.
- RossBencina 1y ago
  > but I don’t get the “hate” I will put forward some arguments. I do not believe all of them: GC is for lazy programmers who do not know how to manage memory. GC takes aspects of memory allocation out of my control. If I control all the things I can get the best performance. If you care about performance: when your program does not need GC, GC is is pure overhead. If you care about performance: if you must use GC then you must have a high-performance GC available. So the question is not just GC/no-GC but you have to worry about details of the GC -- it's a leaky abstraction. If you care about average latency: if you must use GC then you must have a low-latency GC available (i.e. a GC with low and bounded pause times) If you care about meeting real-time deadlines: if you must use GC then you must have a GC that is guaranteed to meet your timing constraints. Corollary of the previous three points: GC is not just GC. Someone else's GC is often not the GC you want. Your program requirements can impose strong requirements on the GC algorithm, and you don't always have the necessary control over the GC. For a particular language, GC algorithm and/or implementation can be a moving target. If the GC developer's goals don't stay aligned with your requirements then you are hosed. GC results in unpredictable memory allocation performance. Ironing out these performance issues (e.g. by avoiding allocations, pooling objects, etc.) is just as much work as using manual memory allocation, so why bother with GC. Unless you have allocation patterns or other requirements that really need GC[0], it's easier to just avoid GC. [0] e.g. some lock-free algorithms depend on the presence of GC
raphaelj 1y ago
Why does he need to manually do the tracing or reference counting of all these nodes? Instead, he could just use the references he needs in the new tree, delete/override the old tree's root node, and expect the Javascript GC to discard all the nodes that are now referenced.
- pdubroy 1y ago
  It's explained in the post: > Then, my plan was to construct a ProseMirror transaction that would turn the old tree into the new one. To do that, it’s helpful to know which nodes appeared in the old document, but not the new one. So, it's not actually about reclaiming the memory. It's about taking some action on the nodes that will be reclaimed. It's akin to a destructor/finalizer, but I need that to happen synchronously at a time that I control. JavaScript does now support finalization (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) but it can't be relied on to actually happen, which makes it useless in this scenario.
veunes 1y ago
It's always fun when a concept you learned years ago suddenly snaps into place for a totally different problem domain

165 points by surprisetalk 1y ago

deleted 1y ago

[deleted]

Had similar epiphanies some many years ago (ugh, I'm old) when I was playing around writing a garbage collected persistent (in the 'stored on [spinny spinny] disk' sense not the FP sense of the word) programming language / runtime. This was back when it was roughly infeasible to be holding large "worlds" of objects purely in-memory on machines of the style of the time, so intelligently paging objects in and out was imperative. (Aside, I think with the recent doubling... tripling of RAM prices this area of thinking is now again more imperative)... In any case, if one is doing GC in such a language, a full tracing collector (whether copying or mark & sweep) is madness, as to find live references means walking nearly the entire heap including the portions living in secondary storage, and now you're in a world of pain. In this case, an intelligent cycle collecting garbage collector in the Bacon style was the answer. You keep in in-memory table of reference counts, and you only trace when you hit cycles. [and hopefully design your language semantics to discourage cycles]

nxobject 1y ago
I’m curious - did fragmentation end up being a significant issue, whether in memory or offloaded?
- cmrdporcupine 1y ago
  I never got far enough to push that into a production system but I suspect it would have, yes. I can see a periodic compacting phase could be useful in a system like that. In the DB world there's good research around similar topics. e.g. LeanStore and Umbra -- Umbra in particular does some nice things with variable sized buffers that I believe are expected to help with fragmentation https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf
- rurban 1y ago
  In real-world copying collectors defragmentation has about 6% time benefits. before - after. mark-sweep obviously not, as it does not defragment and also stops the world.
lisper 1y ago
> you only trace when you hit cycles How do you tell when you've hit a cycle? > hopefully design your language semantics to discourage cycles Why? Cyclical structures can be very useful. For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. [UPDATE] Two responses have now pointed out that this particular case can be handled with weak pointers. But then I can just point to a general graph as an example where that won't work.
- vlovich123 1y ago
  > For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. Does it frequently need an owning reference though or would a weak reference suffice? Usually the latter situation suffices.
  - lisper 1y ago
    A fair point, but then you're still putting the burden on the programmer to figure out where a weak reference is appropriate. But then I'll just choose a different example, like a general graph.
- zozbot234 1y ago
  > For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. That's not a true cycle, it's just a back link for which "weak" reference counts suffice. The containment relation implies that the container "owns" the object, so we don't need to worry about the case where the container might just go away without dropping its contents first. (Edit: I agree that when dealing with a truly general graph some form of tracing is the best approach. These problem domains are where tracing GC really helps.)
  - lisper 1y ago
    OK, then I'll pick a different example: a general graph.

alimw 1y ago

Is it possible that by knowing less about garbage collection in Java this person might have arrived at the same solution earlier? After all his initial construction of a tracing garbage collector was wasted effort.

pdubroy 1y ago
(OP here) It’s possible, but I doubt it. Perhaps the way I wrote it makes it sound like I was thinking about it as a GC problem from the beginning, but I wasn’t. It wasn’t until I started seeing it as as being like GC that (a) I realized that my naive solution was akin to tracing GC, and (b) I came up with the reference counting solution.
weitendorf 1y ago
If Grug worry about garbage collector, it mean Grug working on problem already solved by Sun Microsystems instead of problem Grug paid to solve. Except, if someone want to pay Grug to work on garbage collector for javascript framework, Grug put in position where Grug learns what Grug don't already know about it because it now Grug's job. So Grug understand why Sun solve problem, why problem hard, tell other Grug about isomorphisms between spanning trees. Now other Grug know more about what other Grug don't know, why other Grug not make same mistake of knowing better than Sun Microsystems either.

ClimatePaywall 1y ago

[dead]

keith_analog 1y ago

My favorite quote from Alan Perlis: “Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere.”

summa_tech 1y ago
Unfortunately, the symmetry provided by higher levels of your software stack is not always reflected by the lower levels. This causes your symmetry to be created as an abstraction. (Subroutines are more efficient to implement than co-routines on real hardware.) Abstractions are leaky and this, in turn, causes the superficial symmetry to merely mask the underlying asymmetry. If done exceptionally well, the only visible evidence of the leak will be substantial performance disparities between seemingly symmetric features (well done! this is unusual). If done with the normal level of software design quality, the evidence will show up as quirky behavior, imperfect symmetry, "well this one always works but the other one is not reentrant", etc.
artemonster 1y ago
Yes! Subroutine call is a) allocation of activation record b) switching context c) returning that combines de-alloc and switch. while coroutines have all of these concepts separated. Why not start with a powerful and general concept and optimize for that one?
- aw1621107 1y ago
  > Why not start with a powerful and general concept and optimize for that one? As with basically everything, there are tradeoffs involved. Sometimes restrictions can be helpful for keeping things understandable, which can in turn make optimizations easier to implement. As a rather hamfisted example: completely unrestricted goto. Very general, debatably powerful, but relatively easy to use in a way that makes comprehension difficult. That same generality can also make it difficult to verify that optimizations don't change observable program semantics compared to something more restricted.
- cryptonector 1y ago
  Because you can allocate the activation record on the heap, provide a way to reify continuations, and presto! now you have call/cc (and trivially implemented, no less)! Price paid: a) you need a GC (ok, whatever, sure, you have one), b) well, the performance hit of having to GC activation records (you don't care; others do), c) whoops, thread-safety got much harder and maybe you can't even have threads (imagine two threads executing in the same activation record at the same time!). That's a very very steep price.

kazinator 1y ago

Reference counting does not trace dead objects. Most of its activity is concerned with maintaining reference counts on live objects. When a reference count hits zero, that's when refcounting begins to be concerned with a dead object; and that part of its operation corresponds to the sweep activity in garbage collection, not to the tracing of live objects. It is not a dual to garbage collection concerned with its negative spaces; it's simply a less general (we could legitimately say lesser) garbage collection that doesn't deal with cycles on its own.

moregrist 1y ago
> it's simply a less general (we could legitimately say lesser) garbage collection that doesn't deal with cycles on its own. There are different implementation and performance trade-offs associated with both. I’ll focus on the two that are most meaningful to me. Reference counting can be added as a library to languages that don’t want or can’t have a precise garbage collector. If you work in C++ (or Rust), it’s a very viable way to assure that you have some measure of non-manual clean up while maintaining precise resource control. Similarly, when performance matters reference counting is essentially deterministic much easier to understand and model. In a lot of situations, garbage collection is an overall better strategy, but it’s not a strict superset, and not always the right choice.
- kazinator 1y ago
  > There are different implementation and performance trade-offs associated with both. They are not the same because there are "semantic tradeoffs".
- mbac32768 1y ago
  > Similarly, when performance matters reference counting is essentially deterministic much easier to understand and model. Is it? What happens if you remove that one last reference to a long chain of objects? You might unexpectedly be doing a ton of freeing and have a long pause. And free itself can be expensive.
  - 1y ago

foota 1y ago

Am I missing something? "This was the answer I needed! Rather than visiting all the live objects, I wanted to only visit the dead ones, and reference counting would let me do that. So I added a way of maintaining a reference count for all the nodes in the doc. When we produce a new document, we decrement the reference count of the old root node (it will always be 0 afterwards). So we recursively decrement the ref count of its children, and so on. This gives me exactly what I wanted — a way to find all the nodes that were not reused, without having to visit most of the nodes in the doc." I think there's a bit missing from the description here in the and so on, you would only recurse on a node when it's new refcount is zero, right (and the set of zero refcount nodes produced is exactly the set of dead nodes)? Isn't this sort of just like having a dirty flag on nodes, and then replacing dirty nodes?

iddan 1y ago
Which is garbage collection?
- foota 1y ago
  Yeah, all I'm saying is I felt the description of how it worked was missing a few pieces.

agentultra 1y ago

I’ve often noted that most projects of a certain size tend to implement some form of garbage collection and allocation. Perhaps general purpose systems of these sorts aren’t suitable for specialized applications… but I don’t get the “hate” (if you can call it that) which some programmers have for GC.

cogman10 1y ago
As someone that likes GCs, I understand it. GCs have a lot of tradeoffs involved. It's impossible to check all boxes and that means that there's going to be something to gripe about. If you want your GC to be memory efficient you are likely trading off throughput. If you want your GC to allocate fast and avoid memory fragmentation, you are likely over-provisioning the heap. If you want to minimize CPU time in GC, you'll likely increase pause time. If you want to minimize pause time, you'll likely increase CPU time doing a GC. All these things can make someone ultimately hate a GC. However, if you want a programming language which deals with complicated memory lifetime (think concurrent datastructures) then a GC is practically paramount. It's a lot harder to correctly implement something like Java's "ConcurrentHashMap" in C++ or Rust.
surajrmal 1y ago
For specific use cases, it's not only more ergonomic, it can be more performant. Look at Linux kernel use of RCU. The important thing is to maintain control over the allocation strategy and lifetime of data depending on the use case for systems programming. Defaulting to a GC just removes your control which is the problem. GC itself is not problematic.
RossBencina 1y ago
> but I don’t get the “hate” I will put forward some arguments. I do not believe all of them: GC is for lazy programmers who do not know how to manage memory. GC takes aspects of memory allocation out of my control. If I control all the things I can get the best performance. If you care about performance: when your program does not need GC, GC is is pure overhead. If you care about performance: if you must use GC then you must have a high-performance GC available. So the question is not just GC/no-GC but you have to worry about details of the GC -- it's a leaky abstraction. If you care about average latency: if you must use GC then you must have a low-latency GC available (i.e. a GC with low and bounded pause times) If you care about meeting real-time deadlines: if you must use GC then you must have a GC that is guaranteed to meet your timing constraints. Corollary of the previous three points: GC is not just GC. Someone else's GC is often not the GC you want. Your program requirements can impose strong requirements on the GC algorithm, and you don't always have the necessary control over the GC. For a particular language, GC algorithm and/or implementation can be a moving target. If the GC developer's goals don't stay aligned with your requirements then you are hosed. GC results in unpredictable memory allocation performance. Ironing out these performance issues (e.g. by avoiding allocations, pooling objects, etc.) is just as much work as using manual memory allocation, so why bother with GC. Unless you have allocation patterns or other requirements that really need GC[0], it's easier to just avoid GC. [0] e.g. some lock-free algorithms depend on the presence of GC

raphaelj 1y ago

Why does he need to manually do the tracing or reference counting of all these nodes? Instead, he could just use the references he needs in the new tree, delete/override the old tree's root node, and expect the Javascript GC to discard all the nodes that are now referenced.

pdubroy 1y ago
It's explained in the post: > Then, my plan was to construct a ProseMirror transaction that would turn the old tree into the new one. To do that, it’s helpful to know which nodes appeared in the old document, but not the new one. So, it's not actually about reclaiming the memory. It's about taking some action on the nodes that will be reclaimed. It's akin to a destructor/finalizer, but I need that to happen synchronously at a time that I control. JavaScript does now support finalization (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) but it can't be relied on to actually happen, which makes it useless in this scenario.

veunes 1y ago

It's always fun when a concept you learned years ago suddenly snaps into place for a totally different problem domain