On 4 February 2014 15:22, Jerry <[email protected]> wrote: > Manu <[email protected]> writes: > > > These are the problems: > > * GC stalls for long periods time at completely un-predictable moments. > > * GC stalls become longer *and* more frequent as memory becomes less > > available, and the working pool becomes larger (what a coincidence). > > * Memory footprint is unknowable, what if you don't have a virtual > memory > > manager? What if your total memory is measured in megabytes? > > * It's not possible to know when destruction of an object will happen, > which > > has known workarounds (like in C#) but is also annoying in many cases, > and > > supports the prior point. > > > > Conclusion: > > GC is unfit for embedded systems. One of the most significant > remaining and > > compelling uses for a native systems language. > > Hi Manu, > > Doing a bit of searching, I came across the Metronome GC that IBM came > up with. It appears to try to address the problems you raise: > > http://researcher.watson.ibm.com/researcher/view_project_subpage.php?id=175 > > Any thoughts? >
Interesting. I'll read :) I know nothing about it, so I can't really comment. And I'm also not an authority on what can/can't be done in terms of GC implementation in the context of D.
