2 ms·

And contrast again with Erlang's approach, where each process (actor) keeps its own heap, which can just be thrown away once the request handling process is don

• jashmatthews 8y ago
  It does have a lot of overhead in copying, though. Erlang has lower throughput than Ruby in a lot of cases. It's somewhat mitigated by the reference counted global heap for passing large messages by reference but multi-threaded reference counting is extremely hard to do fast and AFAIK Erlang doesn't really try and do anything too complex.
  • derefr 8y ago
    Erlang doesn’t usually need to do anything fancy with shared binary refcounts across processes, though, since in most workloads you’ve got a small number of processes sharing the binary (e.g. one transport + one request handler in HTTP), and the refcount in the shared-binaries table only needs to be synchronously updated when a process gets its first/loses its last reference. Shared-binary refcounts are process-grained. That is: each Erlang process will allocate a single local handle to hold a reference to a given shared heap binary, and then all the slices of that shared binary in that process are pointers to that single process-arena-local handle. So you only actually have to update the refcount cross-thread when the entire binary goes out of scope, which will only happen once per request (either when all process-local references to it are found to be dead during a GC sweep on a long-lived process; or, more often, when the process’s arena is deallocated at process exit.)