Re:Go GC: Solving the Latency Problem in Go 1.5
by pjmlp on Thursday July 09, 2015 @04:35AM
(#9856761)
There are JVMs with RC,
http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oops...
Re:Go GC: Solving the Latency Problem in Go 1.5
by amenghra on Wednesday July 15, 2015 @10:39PM
(#9895241)
Very interesting, thanks for sharing.
Often, the problem with this kind of academic work is that they don't have a real world system to gather data and study different algorithms. I don't really care if javac (one of the application they benchmark) takes 10% more or less time. I want to know how much time engineers save when using ARC vs tracing GC over a long period of time (development + maintenance).
Re:Go GC: Solving the Latency Problem in Go 1.5
by Skinney on Thursday July 09, 2015 @04:49AM
(#9856804)
You loose the predictability if you get longer pause-times. Memory leaks can also severely hurt development time when you spend days or weeks chasing down memory leaks (personal experience). You're not immune to memory leaks (space leaks really) in a GC based system, but it's generally easier to reason about where the system is using memory.
In regards to resources, who depends on lifecycles in a GC based system to handle resources? try-with-resources in Java is just as predictable as destructors in C++, with the added benefit of resources being eventually closed in case you forget to close it (wheras a memory leak in C++ will never close said resource)
I think it's too bad that the GC/ARC choice also implies a language choice. For e.g. if we had the ability to choose between GC & ARC in Java, we would be able to get a better understanding of which memory model developers of Java enterprise software end up preferring.