3 ms·
Besides the issues that jerf mentioned, Erlang also has per-process garbage collection built right into the VM. Last time I checked Go's garbage collection was
by waffle_ss 13y ago
Besides the issues that jerf mentioned, Erlang also has per-process garbage collection built right into the VM. Last time I checked Go's garbage collection was still stop-the-world, mark-and-sweep, making it less suitable for soft real-time systems than Erlang.
- jerf 13y ago"Go 2.0" probably can't ever quite fix that, but there's some potential for improvement; one can imagine as an optimization the compiler being able to determine a particular goroutine really is isolated (no shared state with anything else at start time, communicates only via channels that are full copiers of state, etc.) and independently GC's them, and also excludes them from the "stop" in the "stop the world". But yes, it is stop-the-world, and I'm keeping a close eye on the GC performance in the app I'm transitioning. (So far the numbers are working out OK, but it's definitely in the range I have to watch out.)
- waffle_ss 13y agoYeah I don't doubt there are some smart people out there that could make something like that happen (look at Azul and their pauseless GC for the JVM for example). However, it will be a tough fix when compared to the simple/pure approach Erlang takes.
- erichocean 13y agoFor the life of me, I cannot understand why Oracle hasn't bought Azul and made it available to all, for free. Azul only works well on multi-processor machines with LOTS of RAM, but when it does, it beats everything else out there by a mile. You'd think Oracle would want that.
- deleted 13y ago[deleted]
- voidlogic 13y agoThe Go situation is changing: runtime: concurrent GC sweep Moves sweep phase out of stoptheworld by adding background sweeper goroutine and lazy on-demand sweeping. https://codereview.appspot.com/46430043/ https://codereview.appspot.com/46430043/