<div dir="ltr">On 25 May 2013 11:26, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="im">On 25 May 2013 03:55, deadalnix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>With real time constraint, a memory overhead is better than a pause.<br></div></blockquote></div><div class="im"><div><br></div></div><div>I wouldn't necessarily agree. Depends on the magnitude of each.</div><div>
What sort of magnitude are we talking?</div>
<div>If you had 64mb of ram, and no virtual memory, would you be happy to sacrifice 20% of it? 5% of it?</div></div></div></div></blockquote><div><br></div><div style>Actually, I don't think I've made this point clearly before, but it is of critical importance.</div>
<div style><br></div><div style>The single biggest threat when considering unexpected memory-allocation, a la, that in phobos, is NOT performance, it is non-determinism.</div><div style>Granted, this is the biggest problem with using a GC on embedded hardware in general.</div>
<div style><br></div><div style>So let's say I need to keep some free memory over-head, so that I don't run out of memory when a collect hasn't happened recently...</div><div style>How much over-head do I need? I can't afford much/any, so precisely how much do I need?</div>
<div style>Understand, I have no virtual-memory manager, it won't page, it's not a performance problem, it will just crash if I mis-calculate this value.</div><div style>And does the amount of overhead required change throughout development? How often do I need to re-calibrate?</div>
<div style>What about memory fragmentation? Functions that perform many small short-lived allocations have a tendency to fragment the heap.</div><div style><br></div><div style>This is probably the most critical reason why phobos function's can't allocate internally. General realtime code may have some small flexibility, but embedded use has hard limits.</div>
<div style>So we need to know where allocations are coming from for reasons of determinism. We need to be able to tightly control these factors to make confident use of a GC.</div><div style><br></div><div style>The more I think about it, the more I wonder if ref-counting is just better for strictly embedded use across the board...?</div>
<div style>Does D actually have a ref-counted GC? Surely it wouldn't be particularly hard? Requires compiler support though I suppose.</div></div></div></div>