4 ms·

As far as I know the biggest diffeence between Erlang’s GC and other GC algorithms is that the former only has to work on a small local heap. This also works t

by kaba0 4y ago

As far as I know the biggest diffeence between Erlang’s GC and other GC algorithms is that the former only has to work on a small local heap. This also works to a degree in Java with thread local allocation buffers. Objects get allocated on a thread local basis and only move to a shared heap generation when they lived for long enough, or are being shared to another thread.

zozbot234 4y ago
> As far as I know the biggest diffeence between Erlang’s GC and other GC algorithms is that the former only has to work on a small local heap. This is also the biggest potential upside of "pluggable", optional GC in a language like Rust. In most programs, the size of a group of references that might form an ownership-relevant cycle is naturally quite small; for the most part memory can be managed with simple RAII, and even refcounting (where multiple "owners" might be extending the lifecycle of a single object) really is quite rare. Leaving open the possibility of GC allows for expressing more programs, without reducing performance.
- kaba0 4y ago
  > for the most part memory can be managed with simple RAII, and even refcounting (where multiple "owners" might be extending the lifecycle of a single object) really is quite rare This is absolutely not my experience. I believe there is a bias here between developers using mainly low- or high-level languages, but these nested lifetimes are common in the former because these developers have learned to form such lifetimes, and are biased towards those. In plenty of areas lifetimes are very very dynamic (any language interpreter/symbolic processing, but even web backends).
  - zozbot234 4y ago
    Keep in mind that in most GC languages every reference between data objects is inherently managed by GC. That's where much of the overhead comes from, needing to repeatedly trace the full set of program references. Whereas it's absolutely not the case that most references in a real-world program will even be relevant to object lifecycle, let alone be involved in a case where such lifecycle is "dynamically" being extended by multiple objects.
    - kaba0 4y ago
      > That's where much of the overhead comes from, needing to repeatedly trace the full set of program references No modern GC goes over naively the full application, generational GCs basically group together objects and cache their inter-generational references. Also, I don’t really get what you mean. What reference could be - regardless of language - that is not related to the life cycle of the targeted data? That reference can only be invalid in such case, so, the inverse of the life cycle which is absolutely related. Sure, a pointer can be encoded many smart ways, but in the end they either point to a semantically correct data location or not.
      - zozbot234 4y ago
        Generational GC's simply have multiple "generations" assigned by age, that get traced at different frequencies - the "younger" generation more frequently than "older" ones. Any caching involved is strictly temporary and does not obviate the need to "go over" the full set at some point. The alternative is a lot of memory overhead. > What reference could be - regardless of language - that is not related to the life cycle of the targeted data? If a program reference can be statically proven to never outlive the object it targets, it's per se irrelevant to that object's lifecycle. That's what the borrowck pass in Rust is all about.
        kaba0 4y ago
        Indeed, so generational GCs don’t in fact scan the whole heap all the time, which was my point. That‘s just an optimization. You explicitly made the lifecycle requirement part of the semantics.

by kaba0 4y ago

zozbot234 4y ago

> As far as I know the biggest diffeence between Erlang’s GC and other GC algorithms is that the former only has to work on a small local heap. This is also the biggest potential upside of "pluggable", optional GC in a language like Rust. In most programs, the size of a group of references that might form an ownership-relevant cycle is naturally quite small; for the most part memory can be managed with simple RAII, and even refcounting (where multiple "owners" might be extending the lifecycle of a single object) really is quite rare. Leaving open the possibility of GC allows for expressing more programs, without reducing performance.

kaba0 4y ago
> for the most part memory can be managed with simple RAII, and even refcounting (where multiple "owners" might be extending the lifecycle of a single object) really is quite rare This is absolutely not my experience. I believe there is a bias here between developers using mainly low- or high-level languages, but these nested lifetimes are common in the former because these developers have learned to form such lifetimes, and are biased towards those. In plenty of areas lifetimes are very very dynamic (any language interpreter/symbolic processing, but even web backends).
- zozbot234 4y ago
  Keep in mind that in most GC languages every reference between data objects is inherently managed by GC. That's where much of the overhead comes from, needing to repeatedly trace the full set of program references. Whereas it's absolutely not the case that most references in a real-world program will even be relevant to object lifecycle, let alone be involved in a case where such lifecycle is "dynamically" being extended by multiple objects.
  - kaba0 4y ago
    > That's where much of the overhead comes from, needing to repeatedly trace the full set of program references No modern GC goes over naively the full application, generational GCs basically group together objects and cache their inter-generational references. Also, I don’t really get what you mean. What reference could be - regardless of language - that is not related to the life cycle of the targeted data? That reference can only be invalid in such case, so, the inverse of the life cycle which is absolutely related. Sure, a pointer can be encoded many smart ways, but in the end they either point to a semantically correct data location or not.
    - zozbot234 4y ago
      Generational GC's simply have multiple "generations" assigned by age, that get traced at different frequencies - the "younger" generation more frequently than "older" ones. Any caching involved is strictly temporary and does not obviate the need to "go over" the full set at some point. The alternative is a lot of memory overhead. > What reference could be - regardless of language - that is not related to the life cycle of the targeted data? If a program reference can be statically proven to never outlive the object it targets, it's per se irrelevant to that object's lifecycle. That's what the borrowck pass in Rust is all about.
      - kaba0 4y ago
        Indeed, so generational GCs don’t in fact scan the whole heap all the time, which was my point. That‘s just an optimization. You explicitly made the lifecycle requirement part of the semantics.