<div dir="ltr">On 30 May 2013 19:50, Rainer Schuetze <span dir="ltr"><<a href="mailto:r.sagitario@gmx.de" target="_blank">r.sagitario@gmx.de</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 class="im"><br>
<br>
On 29.05.2013 10:06, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What do you think is easier, or perhaps even POSSIBLE in D?<br>
A good RC approach, or a V8 quality concurrent+incremental GC?<br>
</blockquote>
<br></div>
I think none of them is feasible without write-barriers on pointer modifications in heap memory. That means extra code needs to be generated for each pointer modification (if the compiler cannot optimize it away as LLVM seems to be doing in case of Objectve-C). As an alternative, Leandros concurrent GC implements them with hardware support by COW, though at a pretty large granularity (page size). I'm not sure if this approach can be sensibly combined with RC or incremental collection.</blockquote>
<div><br></div><div style>I'm talking about embedded hardware. No virtualisation, tight memory limit, no significant OS. Is it possible?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I get the feeling either would be acceptable, but I still kinda like<br>
idea of the determinism an RC collector offers.<br>
</blockquote>
<br></div>
If you want it to be safe and efficient, it needs to use deferred reference counting, and this ain't so deterministic anymore. The good thing about it is that you usually don't have to scan the whole heap to find candidates for reclamation.</blockquote>
<div><br></div><div style>Well, it's a bit more deterministic, at least you could depend on the deferred free happening within a frame let's say, rather than at some un-knowable future time when the GC feels like performing a collect...</div>
<div><br></div><div style>That said, I'd be interested to try it without a deferred free. Performance impact depends on the amount of temporaries/frees... I don't imagine it would impact much/at-all since there is so little memory allocation or pointer assignments in realtime software.</div>
<div style>People use horrific C++ smart pointer templates successfully, without any compiler support at all. It works because the frequency of pointer assignments is so low.</div><div style>RC is key to avoid scanning the whole heap, which completely destroys your dcache.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I reckon this should probably be the next big ticket for D. The<br>
long-standing shared library problems seem to be being addressed.<br>
</blockquote>
<br></div>
The GC proposed by Leandro looks very promising, though it needs support by the hardware and the OS. I think we should see how far we can get with this approach.<br>
</blockquote></div><br></div><div class="gmail_extra" style>His GC looked good, clearly works better for the sociomantic guys, but I can't imagine it, or anything like it, will ever work on embedded platforms?</div><div class="gmail_extra" style>
No hardware/OS support... is it possible to emulate the requires features?</div></div>