3 ms·

There's a difference between GC'ing the memory reachable from an actor and GC'ing the actors themselves. Erlang requires a "poison pill" message to kill actors.

There's a difference between GC'ing the memory reachable from an actor and GC'ing the actors themselves. Erlang requires a "poison pill" message to kill actors. The research paper is here: http://ponylang.org/papers/opsla237-clebsch.pdf http://ponylang.org/papers/opsla237-clebsch.pdf

istvan__ 11y ago
Also, looking at the white paper I see really weird numbers. This section in particular: Benchmarks and preliminary comparisons with Erlang, Scala, Akka, and libccpa Table1 & Table2 It seems that you have the exact same numbers for Erlang and Scala in table2, this is very hard to believe. You either accidentally put down the same number twice or you measured the performance of your benchmarking tool, otherwise it is extremely unlikely that two entirely different systems give the the same exact measurement. Similar story in table1. maybe I am missing something terribly obvious but this looks off to me.
- pedrocr 11y ago
  >It seems that you have the exact same numbers for Erlang and Scala in table2, this is very hard to believe. The numbers are taken from another source and it seems they didn't have the exact numbers, hence the ~9s figure which is then used to calculate 333,333. They seem to have gotten the numbers by looking up the graphs on this page: http://libcppa.blogspot.co.uk/search/label/benchmark http://libcppa.blogspot.co.uk/search/label/benchmark Makes me wonder how precise you could be at getting the numbers from just the graphs. Pixel precision at 800x600 is probably not too bad.
  - wpietri 11y ago
    I am not an expert in benchmarking, so maybe I'm missing something. But how is that not crazy? If I were looking to compare two things, I would run all the benchmarks on a single machine under my control. I might look at previously published reports to make sure I was getting comparable numbers. But there is no way I would publish a comparison that I merely hoped was apples to apples. I've just had too many benchmarks depend on subtle issues, ones that I had presumed were irrelevant.
    - decklebench 11y ago
      The benchmarks reported on the web page (http://ponylang.org http://ponylang.org) and also reported at http://ponylang.org/papers/fast-cheap.pdf http://ponylang.org/papers/fast-cheap.pdf are more recent, and for these the code was run for different languages, and on one machine.
  - istvan__ 11y ago
    I am checking the source code of this benchmark and trying to reproduce the numbers.
istvan__ 11y ago
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.
- 0cachecoherency 11y ago
  If you're interested in the object GC portion, there's this: http://ponylang.org/papers/OGC.pdf 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 http://ponylang.org/papers/fast-cheap.pdf
  - istvan__ 11y ago
    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.
    - jlouis 11y ago
      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.
rdtsc 11y ago
Can you explain some more or point to the exact part of the research paper. When you say "GC'ing actors themselves vs GC'ing memory reachable from actor" what exactly do you mean? Are you talking about the process dictionary and mailbox vs the state of actor passed through its loop function? For arguments' sake here is what a simple Erlang actor looks like: loop(State) -> ... loop(NewState). ... Maybe you can spawn it with: Pid = spawn(fun () -> loop(InitState) end)
- Matthias247 11y ago
  I guess the claim was that such an erlang actor would run forever when nobody sends it a message to stop it. And with pony it would be detected that the actor is no longer reachable and it would be automatically stopped.
  - SnowyOwl 11y ago
    Indeed, Pony can automatically detect actors with empty stacks and message queues, also when these are part of a cycle.
  - rdtsc 11y ago
    Erlang has something like that as well: http://erldocs.com/17.3/erts/erlang.html#hibernate/3 http://erldocs.com/17.3/erts/erlang.html#hibernate/3 Hibernate compresses the current memory, save it and then kill the active process. Then if a message is sent to it, it "wakes" up.

istvan__ 11y ago

Also, looking at the white paper I see really weird numbers. This section in particular: Benchmarks and preliminary comparisons with Erlang, Scala, Akka, and libccpa Table1 & Table2 It seems that you have the exact same numbers for Erlang and Scala in table2, this is very hard to believe. You either accidentally put down the same number twice or you measured the performance of your benchmarking tool, otherwise it is extremely unlikely that two entirely different systems give the the same exact measurement. Similar story in table1. maybe I am missing something terribly obvious but this looks off to me.

pedrocr 11y ago
>It seems that you have the exact same numbers for Erlang and Scala in table2, this is very hard to believe. The numbers are taken from another source and it seems they didn't have the exact numbers, hence the ~9s figure which is then used to calculate 333,333. They seem to have gotten the numbers by looking up the graphs on this page: http://libcppa.blogspot.co.uk/search/label/benchmark http://libcppa.blogspot.co.uk/search/label/benchmark Makes me wonder how precise you could be at getting the numbers from just the graphs. Pixel precision at 800x600 is probably not too bad.
- wpietri 11y ago
  I am not an expert in benchmarking, so maybe I'm missing something. But how is that not crazy? If I were looking to compare two things, I would run all the benchmarks on a single machine under my control. I might look at previously published reports to make sure I was getting comparable numbers. But there is no way I would publish a comparison that I merely hoped was apples to apples. I've just had too many benchmarks depend on subtle issues, ones that I had presumed were irrelevant.
  - decklebench 11y ago
    The benchmarks reported on the web page (http://ponylang.org http://ponylang.org) and also reported at http://ponylang.org/papers/fast-cheap.pdf http://ponylang.org/papers/fast-cheap.pdf are more recent, and for these the code was run for different languages, and on one machine.
- istvan__ 11y ago
  I am checking the source code of this benchmark and trying to reproduce the numbers.

istvan__ 11y ago

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.

0cachecoherency 11y ago
If you're interested in the object GC portion, there's this: http://ponylang.org/papers/OGC.pdf 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 http://ponylang.org/papers/fast-cheap.pdf
- istvan__ 11y ago
  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.
  - jlouis 11y ago
    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.

rdtsc 11y ago

Can you explain some more or point to the exact part of the research paper. When you say "GC'ing actors themselves vs GC'ing memory reachable from actor" what exactly do you mean? Are you talking about the process dictionary and mailbox vs the state of actor passed through its loop function? For arguments' sake here is what a simple Erlang actor looks like: loop(State) -> ... loop(NewState). ... Maybe you can spawn it with: Pid = spawn(fun () -> loop(InitState) end)

Matthias247 11y ago
I guess the claim was that such an erlang actor would run forever when nobody sends it a message to stop it. And with pony it would be detected that the actor is no longer reachable and it would be automatically stopped.
- SnowyOwl 11y ago
  Indeed, Pony can automatically detect actors with empty stacks and message queues, also when these are part of a cycle.
- rdtsc 11y ago
  Erlang has something like that as well: http://erldocs.com/17.3/erts/erlang.html#hibernate/3 http://erldocs.com/17.3/erts/erlang.html#hibernate/3 Hibernate compresses the current memory, save it and then kill the active process. Then if a message is sent to it, it "wakes" up.