<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 15:22, Jerry <span dir="ltr"><<a href="mailto:jlquinn@optonline.net" target="_blank">jlquinn@optonline.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> writes:<br>
<br>
> These are the problems:<br>
>  * GC stalls for long periods time at completely un-predictable moments.<br>
>  * GC stalls become longer *and* more frequent as memory becomes less<br>
> available, and the working pool becomes larger (what a coincidence).<br>
>  * Memory footprint is unknowable, what if you don't have a virtual memory<br>
> manager? What if your total memory is measured in megabytes?<br>
>  * It's not possible to know when destruction of an object will happen, which<br>
> has known workarounds (like in C#) but is also annoying in many cases, and<br>
> supports the prior point.<br>
><br>
> Conclusion:<br>
>   GC is unfit for embedded systems. One of the most significant remaining and<br>
> compelling uses for a native systems language.<br>
<br>
Hi Manu,<br>
<br>
Doing a bit of searching, I came across the Metronome GC that IBM came<br>
up with.  It appears to try to address the problems you raise:<br>
<br>
<a href="http://researcher.watson.ibm.com/researcher/view_project_subpage.php?id=175" target="_blank">http://researcher.watson.ibm.com/researcher/view_project_subpage.php?id=175</a><br>
<br>
Any thoughts?<br></blockquote><div><br></div><div>Interesting. I'll read :)</div><div>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.</div>
</div></div></div>