Hacker News Reader

Comment by istvan__ | Hacker News Reader

There is but what is relevant from the design of the Erlang concurrent GC is that your actor operations latency is not impacted by it. This is why Erlang is extremely suitable for HTTP routers and request dispatch because you can maintain tight SLA on the p99.99 latency as opposed something like JVM where the GC locks up all of the executions, or at least this used to be the case.

View on HN

If you're interested in the object GC portion, there's this:

http://ponylang.org/papers/OGC.pdf

The Pony object garbage collector is fully concurrent, the reachable memory for any actor is GC'd totally independently. At the same time, Pony allows (safely, with no data races) sharing pointers across actors, for performance (ie without copying).

There's a paper on the type system that allows this:

http://ponylang.org/papers/fast-cheap.pdf

What I am saying is that the Erlang GC is good enough from the practical point of view. I am not sure what value are you trying to add with the "fully concurrent" GC.

It's not the same thing. The post is talking about automatically figuring out that nobody knows the Pid of a process and hence that process can be reclaimed. This is a transitive notion: If a group of processes can't be "reached" from another group and the latter group is the "important" one, then you can just kill off the first group of proceses. This is why it is GC-like behaviour. Like in a GC, processes can "leak" if you forget to throw the Pid away.

Erlang's method is to form linked webs of processes and then the death of a process "poisons the web" and kills off all processes in the web. By trapping exits, you can put in stopgaps for this behaviour, which is what supervisors do, among other things.

Process handling in Erlang is more akin to "manual memory management" or ARC/RAII style memory management here.

Thanks, I just try to understand the practical advantage of this different approach.

It's like jlouis said, with Erlang you have to kill your processes off when you've finished with them and if you don't they leak. In Pony that's done for you automatically.

Thanks, I think you end up killing your Erlang processes most of the time because this is the model you follow when programming in Erlang. Using HTTP as example, while in other systems it is a really bad idea to have 1 req -> 1 process (or thread) mapping in Erlang it is encouraged. When the request is answered and the response is sent back the process dies. I think is a fairly simple model. I guess I need to look into Pony more to understand the importance of this in it.

> The post is talking about automatically figuring out that nobody knows the Pid of a process and hence that process can be reclaimed.

This seems pretty impossible in distributed Erlang. Perhaps the Pid was sent to another node (which may be alive but not currently dist connected), or was serialized and may be deserialized later.

Reply on news.ycombinator.com