| |||||||||||||
Real-time GC does not work, period.Real-time GC does not work, period.Posted Jun 17, 2010 10:57 UTC (Thu) by khim (subscriber, #9252)In reply to: Pauses by flewellyn Parent article: The Managed Runtime Initiative
Problems with real-time GC is not the GC itself. Rather it's general problem: you can't manage memory efficiently unless the program does it. If you program keeps links to gigabyte of long-dead objects and then suddenly drop links to all these objects to create another gygabyte of objects you'll see UI freezes no matter what you do. And if your program is accurate enough and careful enough with allocation of objects then it's usually easy to add manual allocation or trivial refcounting GC. Good memory management is hard, good memory management with GC is harder. Not only you must think about references to objects - you must keep the capabilities of GC in mind too! GC is great for batch-processing, but real-time? It does not work in practice beyong toy samples.
(Log in to post comments)
Real-time GC does not work, period. Posted Jun 17, 2010 15:49 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Rather it's general problem: you can't manage memory efficiently unless the program does it.
OK...
> And if your program is accurate enough and careful enough with allocation of objects then it's usually easy to add manual allocation or trivial refcounting GC.
If it is trivial then why do I have to do it myself?
See also "GC allows for entirely different algorithms" somewhere here:
Real-time GC does not work, period. Posted Jun 17, 2010 23:28 UTC (Thu) by ncm (subscriber, #165) [Link] It is trivial precisely because you don't have to do it yourself.
Real-time GC does not work, period. Posted Jun 18, 2010 1:07 UTC (Fri) by pflugstad (subscriber, #224) [Link] GC is great for batch-processing, but real-time? It does not work in practice beyond toy samples. Hmmm... Been there, done that: embedded system running RTOS and RT Java, driving an avionics Mil-Std-1553 bus at 50Hz with <30ms latency under heavy load for many hours. Very non-trivial (several hundred thousand LOC). Yes we had to pay attention to memory allocations in the time critical code paths, but that was actually pretty easy. And yes, we used the real-time GC that the RT Java gave us to essentially run in the background. And we had to tune some other parts of the code where some programmers had made some dreadful data structure choices (which worked find under low utilization, but didn't scale). But mostly things worked and we didn't really pay much attention to memory allocations across the majority of the application. No stop-the-world pauses, no burps in latency (which there were before we tuned). The key with the whole thing was to have enough memory available so the GC could come along behind and clean up without having to stop the rest of the system from running. Similar tests on a much more memory constrained device did not scale as well - but not: it is just a matter of scaling. I'd done similar things on Windows with C/C++ and all the explicit memory management, so I'm very aware of the trade-offs. I'll take the GC thank-you-very-much, and RT GC does work just fine, IMO.
|
|||||||||||||