<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 06:52, Adam Wilson <span dir="ltr"><<a href="mailto:flyboynw@gmail.com" target="_blank">flyboynw@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, 03 Feb 2014 12:40:20 -0800, Dmitry Olshansky <<a href="mailto:dmitry.olsh@gmail.com" target="_blank">dmitry.olsh@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
04-Feb-2014 00:21, Adam Wilson пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu<br>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><u></u>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/3/14, 6:57 AM, Frank Bauer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyone asking for the addition of ARC or owning pointers to D, gets<br>
pretty much ignored. The topic is "Smart pointers instead of GC?",<br>
remember? People here seem to be more interested in diverting to<br>
nullable, scope and GC optimization. Telling, indeed.<br>
</blockquote>
<br>
I thought I made it clear that GC avoidance (which includes<br>
considering built-in reference counting) is a major focus of 2014.<br>
<br>
Andrei<br>
<br>
</blockquote>
<br>
</blockquote>
...<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sadly, although written as hyperbole, I feel that the above is fairly<br>
close to the actual position of the ARC crowd.<br>
<br>
</blockquote>
<br>
I won't be surprised that half of current GC problems are because it's simply too stupid as an allocator. I had some numbers that I'd need to dig up were GC.malloc was ~2x slower then malloc even with garbage collection disabled.<br>

<br>
With that said I'd focus on ref-counting somehow coexisting with tracing GC. It doesn't go well at the moment - try creating dynamic arrays of std.stdio.File (that is ref-counted).<br>
<br>
</blockquote>
<br></div></div>
I will not defend the current GC, it is about as stupid as you can make one and still have a functioning memory management system. It implements exactly none of the optimizations recommended for Mark-Sweep GC's in the GC Handbook.<br>

<br>
That said, I firmly believe that wholesale replacement of the GC is throwing the baby out with the bathwater. Effectively, the poor D GC implementation has become an excuse to launch a crusade against all GC's everywhere, never mind that Java and the .NET GC's are consistent examples of just how good GC's can actually be.</blockquote>
<div><br></div><div>Point me at a proposal for a GC that satisfies the problems in my prior email, which is realistically implement-able in D, and I'll shut up.</div></div></div></div>