DIP60: @nogc attribute

[Walter Bright via Digitalmars-d]

On 4/16/2014 8:13 PM, Manu via Digitalmars-d wrote:
> On 17 April 2014 03:37, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>     ARC has very serious problems with bloat and performance.
> This is the first I've heard of it, and I've been going on about it for ages.

Consider two points:

1. I can't think of any performant ARC systems.

2. Java would be a relatively easy language to implement ARC in. There's 
probably a billion dollars invested in Java's GC. Why not ARC?


> Obviously, a critical part of ARC is the compilers ability to reduce redundant
> inc/dec sequences. At which point your 'every time' assertion is false. C++
> can't do ARC, so it's not comparable.

C++ has shared_ptr, with all kinds of escapes.


> With proper elimination, transferring ownership results in no cost, only
> duplication/destruction, and those are moments where I've deliberately committed
> to creation/destruction of an instance of something, at which point I'm happy to
> pay for an inc/dec; creation/destruction are rarely high-frequency operations.

inc/dec isn't as cheap as you imply. The dec usually requires the creation of an 
exception handling unwinder to do it.


> Have you measured the impact?

No. I don't really know how I could, as I haven't seen an ARC system.


> I've never heard of Obj-C users complaining about the inc/dec costs.

Obj-C only uses ARC for a minority of the objects.


> How often does ref fiddling occur in reality? My guess is that with redundancy
> elimination, it would be surprisingly rare, and insignificant.

Yes, I would be surprised.

>     Further problems with ARC are inability to mix ARC references with non-ARC
>     references, seriously hampering generic code.
> That's why the only workable solution is that all references are ARC references.
> The obvious complication is reconciling malloc pointers, but I'm sure this can
> be addressed with some creativity.
>
> I imagine it would look something like:
> By default, pointers are fat: struct ref { void* ptr, ref_t* rc; }

First off, now pointers are 24 bytes in size. Secondly, every pointer 
dereference becomes two dereferences (not so good for cache performance).


> malloc pointers could conceivably just have a null entry for 'rc' and therefore
> interact comfortably with rc pointers.
> I imagine that a 'raw-pointer' type would be required to refer to a thin
> pointer. Raw pointers would implicitly cast to fat pointers, and a fat->thin
> casts may throw if the fat pointer's rc is non-null, or compile error if it can
> be known at compile time.

Now we throw in a null check and branch for pointer operations.


> Perhaps a solution is possible where an explicit rc record is not required (such
> that all pointers remain 'thin' pointers)...
> A clever hash of the pointer itself can look up the rc?
> Perhaps the rc can be found at ptr[-1]? But then how do you know if the pointer
> is rc allocated or not? An unlikely sentinel value at ptr[-1]? Perhaps the
> virtual memory page can imply whether pointers allocated in that region are ref
> counted or not? Some clever method of assigning the virtual address space so
> that recognition of rc memory can amount to testing a couple of bits in pointers?
>
> I'm just making things up,

Yes.

> but my point is, there are lots of creative
> possibilities, and I have never seen any work to properly explore the options.

ARC has been known about for many decades. If you haven't seen it "properly 
explored", perhaps it isn't as simple and cost-effective as it may appear at 
first blush.


> So then consider ARC seriously. If it can't work, articulate why. I still don't
> know, nobody has told me.
> It works well in other languages, and as far as I can tell, it has the potential
> to produce acceptable results for _all_ D users.

What other languages?


> iOS is a competent realtime platform, Apple are well known for their commitment
> to silky-smooth, jitter-free UI and general feel.

A UI is a good use case for ARC. A UI doesn't require high performance.


> Okay. Where can I read about that? It doesn't seem to have surfaced, at least,
> it was never presented in response to my many instances of raising the topic.
> What are the impasses?

I'd have to go look to find the thread. The impasses were as I pointed out here.


> I'm very worried about this. ARC is the only imaginary solution I have left. In
> lieu of that, we make a long-term commitment to a total fracturing of memory
> allocation techniques, just like C++ today where interaction between libraries
> is always a massive pain in the arse. It's one of the most painful things about
> C/C++, and perhaps one of the primary causes of incompatibility between
> libraries and frameworks. This will transfer into D, but it's much worse in D
> because of the relatively high number of implicit allocations ('~', closures, etc).

There are only about 3 cases of implicit allocation in D, all easily avoided, 
and with @nogc they'll be trivial to avoid. It is not "much worse".


> Frameworks and libraries become incompatible with each other, which is a problem
> in C/C++ that modern languages (java, C#, python, etc) typically don't suffer.

A GC makes libraries compatible with each other, which is one reason why GCs are 
very popular.