<div dir="ltr">On 28 May 2013 23:33, Steven Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.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 class="im">On Sat, 25 May 2013 01:52:10 -0400, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What does ObjC do? It seems to work okay on embedded hardware (although not<br>
particularly memory-constrained hardware).<br>
Didn't ObjC recently reject GC in favour of refcounting?<br>
</blockquote>
<br></div>
Having used ObjC for the last year or so working on iOS, it is a very nice memory management model.<br>
<br>
Essentially, all objects (and only objects) are ref-counted automatically by the compiler.  In code, whenever you assign or pass a pointer to an object, the compiler automatically inserts retains and releases extremely conservatively.<br>

<br>
Then, the optimizer comes along and factors out extra retains and releases, if it can prove they are necessary.<br>
<br>
What I really like about this is, unlike a library-based solution where every assignment to a 'smart pointer' incurs a release/retain, the compiler knows what this means and will factor them out, removing almost all of them.  It's as if you inserted the retains and releases in the most optimized way possible, and it's all for free.<br>

<br>
Also, I believe the compiler is then free to reorder retains and releases since it understands how they work.  Of course, a retain/release is an atomic operation, and requires memory barriers, so the CPU/cache cannot reorder, but the compiler still can.<br>
</blockquote><div><br></div><div style>Right. This is almost precisely how I imagined it would be working.</div><div style>I wonder what it would take to have this as a GC strategy in D?</div><div style>I'm more and more thinking this would be the best approach for realtime software.</div>
<div style>It's deterministic, and while being safe like a GC, the programmer retains absolute control.</div><div style>Also, things are destroyed when you expect (again, the deterministic thing).</div><div style>I think this GC strategy will open D for use on much more embedded hardware.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I asked David Nadlinger at the conference whether we could leverage this power in LDC, since LLVM is the compiler back-end used by Apple, but he said all those optimization passes are in the Objective-C front-end.<br></blockquote>
<div><br></div><div style>Yeah, this would require D front-end work I'm sure.</div><div style><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

It would be cool/useful to have compiler-native reference counting.  The only issue is, Objective-C is quite object-heavy, and it's statically checkable whether a pointer is an Object pointer or not.  In D, you would have to conservatively use retains/releases on every pointer, since any memory block could be ref-counted.  But just like Objective-C most of them could be factored out.  Add in that D has the shared-ness of the pointer built into the type system, and you may have something that is extremely effective.<br>
</blockquote><div><br></div><div style>Yep, I can imagine it would work really well, if the front-end implemented the logic to factor out redundant inc/dec ref's.</div></div></div></div>