4 ms·

> Each Erlang process has its own stack and heap This is one of the cool things about the Erlang VM. Each process (lightweight thread) has its own heap! In oth

> Each Erlang process has its own stack and heap This is one of the cool things about the Erlang VM. Each process (lightweight thread) has its own heap! In other VMs threads can affect each other by generating garbage and causing GC pauses. In Erlang even the heaps are isolated.

deleted 9y ago
[deleted]
weberc2 9y ago
How valuable is the property that other threads' GCs won't stop your thread if your thread bears its own full stop? It seems like a concurrent collector with a very small STW phase would be preferable. Lastly, the lack of shared memory certainly enables simpler GC schemes like this one, and it precludes all sorts nefarious bugs, but it also makes efficient parallelism impossible in many cases. Depending on your application, that may not be suitable.
- hyperpape 9y ago
  These are good questions. Concurrent compacting collectors are pretty tough however, and a single process STW should be much faster than a global one, since it will be (at worst) proportional in time to the per process heap size.
  - weberc2 9y ago
    I suppose it would need to be compacting; Go seems to get along okay without compaction, presumably because it has value types?
    - tychver 9y ago
      Go trades the complexity of a compacting GC for forcing you to restart the app regularly if you have a workload with plenty of heap allocation.
      - weberc2 9y ago
        Really? I've never heard anyone mention this and I've followed Go for years.
        tychver 9y ago
        Yeah, it mostly happens when you have a server which runs an abnormally large task or payload, causes the heap to grow, and does it in a way that Go can't release the memory back to the OS due to heap fragmentation. I haven't looked at this for a while but I believe it's still an issue. https://github.com/cockroachdb/cockroach/issues/2007 https://github.com/cockroachdb/cockroach/issues/2007 https://github.com/golang/go/issues/18896 https://github.com/golang/go/issues/18896 https://github.com/golang/go/issues/14045 https://github.com/golang/go/issues/14045
    - aidenn0 9y ago
      Go has traded throughput for latency. The throughput of a semispace copying collector is very high for most workloads, but can suffer latency issues. There is literally zero cost to collecting garbage in the nursery with the algorithm described in TFA (a nursery collection has a cost proportional only to the live data), and the cost of allocating in the nursery is just incrementing a single value. However eventually you need to collect the entire heap, and it's still proportional to the size of the live data, which is usually the majority of the heap (since you've already collected the nursery at that point).
      - weberc2 9y ago
        Sorry, I'm confused. Is Go's GC the semispaced copying collector or the TFA? Or neither? Or both?
        aidenn0 9y ago
        TFA == "The Fine Article" so refers specifically to the Erlang Garbage Collector. "Semispace" is one term to refer to the family of garbage collectors that Erlang's derives from. The heap is divided into two spaces, hence "semispace" So Go's GC is neither. Go's gc is tuned for lower latencies, and that tends to rule out moving collectors (there are ways of having incremental moving collectors, but they complicate the runtime a bit).
        weberc2 9y ago
        Ah, thanks for the information and clarification!
- ori_b 9y ago
  Even incremental GC is easier to write if you only have one thread you need to collect for.
- ramchip 9y ago
  On Erlang 20 long GCs run on the thread pool for “dirty” (blocking) tasks, they don’t block a scheduler, so the real-time properties are nice. There have been implementations of Erlang with shared heap in the past, before BEAM became heavily multi-threaded: https://www.researchgate.net/publication/2371933_A_Case_for_the_Unified_Heap_Approach_to_Erlang_Memory_Management https://www.researchgate.net/publication/2371933_A_Case_for_... I think it would be nice to see this tried again. Perhaps the issue is scaling to future systems with potentially hundreds of cores?
- imtringued 9y ago
  The heaps are smaller. The problems with gcs start when you have multi gigabyte heaps. If every heap is only a gigabyte it will take at worst 10ms per collection. (Anecdote) If that is too large then you split your heaps into smaller ones until the pauses are acceptable. Also remember malloc isn't free either it takes time to execute.
- toast0 9y ago
  > How valuable is the property that other threads' GCs won't stop your thread if your thread bears its own full stop? GC on a small heap is fast; especially since the language does not allow for circular references in the heap. Almost always, if you're you've got a large heap in your Erlang process, you're doing it wrong; large data generally belongs somewhere else like ETS, the in memory term storage.

deleted 9y ago

[deleted]

weberc2 9y ago

How valuable is the property that other threads' GCs won't stop your thread if your thread bears its own full stop? It seems like a concurrent collector with a very small STW phase would be preferable. Lastly, the lack of shared memory certainly enables simpler GC schemes like this one, and it precludes all sorts nefarious bugs, but it also makes efficient parallelism impossible in many cases. Depending on your application, that may not be suitable.

hyperpape 9y ago
These are good questions. Concurrent compacting collectors are pretty tough however, and a single process STW should be much faster than a global one, since it will be (at worst) proportional in time to the per process heap size.
- weberc2 9y ago
  I suppose it would need to be compacting; Go seems to get along okay without compaction, presumably because it has value types?
  - tychver 9y ago
    Go trades the complexity of a compacting GC for forcing you to restart the app regularly if you have a workload with plenty of heap allocation.
    - weberc2 9y ago
      Really? I've never heard anyone mention this and I've followed Go for years.
      - tychver 9y ago
        Yeah, it mostly happens when you have a server which runs an abnormally large task or payload, causes the heap to grow, and does it in a way that Go can't release the memory back to the OS due to heap fragmentation. I haven't looked at this for a while but I believe it's still an issue. https://github.com/cockroachdb/cockroach/issues/2007 https://github.com/cockroachdb/cockroach/issues/2007 https://github.com/golang/go/issues/18896 https://github.com/golang/go/issues/18896 https://github.com/golang/go/issues/14045 https://github.com/golang/go/issues/14045
  - aidenn0 9y ago
    Go has traded throughput for latency. The throughput of a semispace copying collector is very high for most workloads, but can suffer latency issues. There is literally zero cost to collecting garbage in the nursery with the algorithm described in TFA (a nursery collection has a cost proportional only to the live data), and the cost of allocating in the nursery is just incrementing a single value. However eventually you need to collect the entire heap, and it's still proportional to the size of the live data, which is usually the majority of the heap (since you've already collected the nursery at that point).
    - weberc2 9y ago
      Sorry, I'm confused. Is Go's GC the semispaced copying collector or the TFA? Or neither? Or both?
      - aidenn0 9y ago
        TFA == "The Fine Article" so refers specifically to the Erlang Garbage Collector. "Semispace" is one term to refer to the family of garbage collectors that Erlang's derives from. The heap is divided into two spaces, hence "semispace" So Go's GC is neither. Go's gc is tuned for lower latencies, and that tends to rule out moving collectors (there are ways of having incremental moving collectors, but they complicate the runtime a bit).
        weberc2 9y ago
        Ah, thanks for the information and clarification!
ori_b 9y ago
Even incremental GC is easier to write if you only have one thread you need to collect for.
ramchip 9y ago
On Erlang 20 long GCs run on the thread pool for “dirty” (blocking) tasks, they don’t block a scheduler, so the real-time properties are nice. There have been implementations of Erlang with shared heap in the past, before BEAM became heavily multi-threaded: https://www.researchgate.net/publication/2371933_A_Case_for_the_Unified_Heap_Approach_to_Erlang_Memory_Management https://www.researchgate.net/publication/2371933_A_Case_for_... I think it would be nice to see this tried again. Perhaps the issue is scaling to future systems with potentially hundreds of cores?
imtringued 9y ago
The heaps are smaller. The problems with gcs start when you have multi gigabyte heaps. If every heap is only a gigabyte it will take at worst 10ms per collection. (Anecdote) If that is too large then you split your heaps into smaller ones until the pauses are acceptable. Also remember malloc isn't free either it takes time to execute.
toast0 9y ago
> How valuable is the property that other threads' GCs won't stop your thread if your thread bears its own full stop? GC on a small heap is fast; especially since the language does not allow for circular references in the heap. Almost always, if you're you've got a large heap in your Erlang process, you're doing it wrong; large data generally belongs somewhere else like ETS, the in memory term storage.