Message don't copy for example Termite (<a href="http://toute.ca/">http://toute.ca/</a>) and this is of course faster for big messages. But there is many good reasons why Erlang is as is. Counting GC is in some cases slower than generating GC especially on multi core. For example, when you do walking tree, in current GC schema you can copy after 1000 reduces small resulting tree and during those reduction you don't GC anything. Contrary counting GC every change of tree and each GC step can take unpredictable different long time. Current GC occurs once after longer period and depend only on size off current data. In result it is faster on single core. There is more fun with multi core. When processes share data (don't copy message), counter for each structure can be accessed by many processes running possibly on many CPU cores. CPU cache don't work well in this case and operation is slow. So counting GC is slow in concurrent environment. Counting GC is not as good as looks in first sight. When there is possibility to pack big messages into binary which is not copied, you are able solve pitfalls of Erlang implementation. And share anything between processes also impact reliability, of course. I don't believe change GC is good idea except you want just try it.<br>
<br>On Thu, Jul 3, 2008 at 2:16 PM, Alpár Jüttner <<a href="mailto:alpar@cs.elte.hu">alpar@cs.elte.hu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
Did anyone consider replacing the garbage collection with reference<br>
counting in the Erlang emulator? How difficult would it be to do?<br>
<br>
Probably, it isn't worth changing in general, but reference counting has<br>
some advantages which are important in some special use cases:<br>
<br>
* Per process memory pools is not necessary.<br>
* Message passing (of large data) will be more efficient as<br>
messages don't have to be physically copied.<br>
* There is no need for garbage collection. GC is for example a<br>
major pitfall in hard real time systems (see e.g.<br>
<a href="http://www.erlang.se/workshop/2007/proceedings/05nicosi.pdf" target="_blank">http://www.erlang.se/workshop/2007/proceedings/05nicosi.pdf</a> )<br>
<br>
Here are the drawbacks I can see now:<br>
<br>
* Higher memory overhead.<br>
* However the memory is less fragmented, so we get back<br>
something in return.<br>
* It is said to be slower. I'm not absolutely convinced about it<br>
though.<br>
* In general, the highest problem with reference counting is that<br>
in case of cross/circular referencing, dead objects will be left<br>
in the memory. However, this cannot happen in Erlang due to the<br>
immutability of the data.<br>
<br>
Regards,<br>
Alpar<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil