Concurrent GC: a good thing?
I found this posting Ocaml vs. F#: Concurrent GC: a good thing? on programming.reddit.com.
On the benefits of spawning a OS new process for concurrency:
This is quite a different approach to concurrency and, in particular, each new process has its own GC.
This is how Erlang works except it uses it's own flyweight processes, not OS processes. And it's absolutely key to Erlang's concurrency, reliability and soft-realtime performance.
Each Erlang process has it's own mini-heap, which helps reduce heap fragmentation overall. Because of Erlang's functional nature, cycles in data-structures are not possible, meaning GC is a much simpler problem. Also completed/failed processes don't need to be GC'd at all, the heaps are simply freed en-mass back to the Erlang VM.
Contrast to shared state threading like Java where the object graph can become a giant tangled ball, any object in any thread can hold a reference to anything else. This why so many Java applications that perform great in benchmarks often slow to a crawl under real world conditions (and why micro benchmarks are one of the worst criteria for choosing a programming language).
Posted June 12, 2007 1:28 PM
Comments
By "functional nature", I'm assuming you mean that you cannot reassign to variables, cannot mutate data structures, etc. But you can certainly have functional languages without mutable state that do allow cyclic data structures... you just have to define it that way. I'm pretty sure Haskell allows something like this (in Erlangesque syntax):
Honestly, it's the only thing lacking in Erlang that really pains me. :) I'd love a more symmetric pattern-matching facility that would allow something like this. The only possible justification for not allowing it that I can see is, as you point out, easy GC.
My trick for getting around it (does no one else need cyclic data structures?) is to create a Ref, create the data structures that reference the Ref, then do a put(Ref, Struct). Which is ugly and stupid and I hate it... anyone have a better idea?
Chris Pine, June 13, 2007 1:49 PM
Re: ListOfOnes
Isn't that more about lazy vs. eager/strict evaluation? In a strictly evaluating system you can always do what you did: wrapper things up to make streams. It just so happens that Haskell made that magically part of the system from the ground-up. While it seems really cool, I am under the impression that at times it can lead to rather bad costs, at least in terms of memory.
But I might be totally clueless.
Raoul Duke, June 13, 2007 6:12 PM
Well, I don't think so. I think it has to do with how you chose the environment when evaluating the right-hand-side (do you include the binding you are in the process of defining, or not?). An eager language would have a tough time in general (meaning where the RHS is a general expression), but could be made to handle built-in constructors (literals) without too much trouble. And a lazy language need not accept this construct... but most do accept something similar because it is an easy feature if you already have laziness.
For practical purposes, you are probably right, though. :) I guess it's like laziness and immutability: you don't *need* immutability for laziness, but it makes it so much easier.
Chris Pine, June 13, 2007 7:57 PM
Post a comment