Mac Apps That Use Garbage Collection Must Move to ARC

[Manu via Digitalmars-d]

On 24 February 2015 at 04:04, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> I think RC is an important tool on our panoply. More so than Walter. But I
> have to say you'd do good to understand his arguments better; it doesn't
> seem you do.

The only argument I can't/haven't addressed is the exception argument,
which I have granted to Walter on authority. I think the other issues
he's presented (at various times over the years, so I'm not sure what
is the current state) can probably be addressed by the language. Scope
seems like it could win us a lot of the problem cases alone, but we'd
need to experiment with it for a year or so before we'll know.

It does annoy me that I can't comment on the exceptions case, but the
fact is I've never typed 'throw' before, and never scrutinised the
codegen.
I have meant to take some time to familiarise myself with whatever
appears out the other end of the compiler for a long time, but all
compilers seem to be different, architectures are probably different
too, and I just haven't found the time for something that has no use
to me other than to argue this assertion with some authority.
Walter has said I should "just compile some code and look at it",
which probably sounds fine if you have any idea what you're looking
for, or an understanding of the differences between compilers. I
don't, it's a fairly deep and involved process to give myself
comprehensive knowledge of exceptions, and it has no value to me
outside this argument.

That said, I'd still be surprised if it was a terminal argument
though. Is it really a hard impasse? Or is it just a big/awkward
burden on the exceptional path? Surely the performance of the unwind
path is irrelevant? Does it bleed into the normal execution path?

My whole point is; where we seem to have no options for meaningful
progress in GC land as evidenced by years of stagnation, I figure it's
the only practical direction we have.
I recognise there is some GC action recently, but I haven't seen any
activity that changes the fundamental problems?


>> What do you want me to do? I use manual RC throughout my code, but the
>> experience in D today is identical to C++. I can confirm that it's
>> equally terrible to any C++ implementation I've used. We have no tools
>> to improve on it.
>
>
> Surely you have long by now written something similar to std::shared_ptr by
> now. Please paste it somewhere and post a link to it, thanks. That would be
> a fantastic discussion starter.

Not really. I don't really use C++; we generally switched from C++
back to C about 8 years ago.
Here's something public of the type I am more familiar with:
https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/resource.d
It's not an excellent example; it's quick and dirty, hasn't received
much more attention than getting it working, but I think it's fairly
representative of a typical pattern, especially when interacting with
C code.
I'm not aware of any reasonable strategy I could use to eliminate the
ref fiddling. 'scope' overloads would have solved the problem nicely.

COM is also an excellent candidate for consideration. If COM works
well, then I imagine anything should work.
Microsoft's latest C++ presents a model for this that I'm generally
happy with; distinct RC pointer type. We could do better by having
implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
scope(T*) would be to T^ and T* like const(T*) is to T* and
immutable(T*).


>> And whatever, if it's the same as C++, I can live with it. I've had
>> that my whole career (although it's sad, because we could do much
>> better).
>> The problem, as always, is implicit allocations, and allocations from
>> 3rd party libraries. While the default allocator remains incompatible
>> with workloads I care about, that isolates us from virtually every
>> library that's not explicitly written to care about my use cases.
>> That's the situation in C++ forever. We're familiar with it, and it's
>> shit. I have long hoped we would move beyond that situation in D
>> (truly the #1 fantasy I had when I first dove in to D 6 years back),
>> but it's a massive up-hill battle to even gain mindshare, regardless
>> of actual implementation. There's no shared vision on this matter, the
>> word is basically "GC is great, everyone loves it, use an RC lib".
>
>
> It doesn't seem that way to me at all. Improving resource management is
> right there on the vision page for H1 2015. Right now people are busy fixing
> regressions for 2.067 (aiming for March 1; probably we won't make that
> deadline). In that context, posturing and stomping the ground that others
> work for you right now is in even more of a stark contrast.

I haven't said that. Review my first post, I never made any claims
about what should/shouldn't be done, or make any demands of any sort.
I just don't have any faith that GC can get us where we want to be. I
was cautiously optimistic for some years, but I lost faith.
I'm also critical (disappointed even) of the treatment of scope. I
hope I'm wrong, like I hoped I was wrong about GC...

There have been lots of people come in here and say "I won't use D
because GC", and I've been defensive against those claims, despite
being as high risk of similar tendencies myself. I don't think you can
say I didn't give GC a fair chance to prove me wrong.


>> How long do we wait for someone to invent a fantastical GC that solves
>> our problems and works in D?
>
>
> This elucubration belongs only to you. Nobody's waiting on that. Pleas read
> http://wiki.dlang.org/Vision/2015H1 again.

This is a bit of a red herring, the roadmap has no mention of ARC, or
practical substitution for the GC. This discussion was originally
about ARC over the GC, specifically.

I firmly understand the push for @nogc. I have applauded that effort many times.
I have said in the past though that I'm not actually a strong
supporter of @nogc, and spoke critically of it initially. I'm still
not really thrilled, but I do agree it's a necessary building block
and I'm very happy it's a key focus, but I'm ultimately concerned it
will lead to a place where separation of users into 2 camps (my
primary ongoing criticism) is firmly established, and it will be
justified by the effort expended to achieve that end.
Again, don't get me wrong, I agree we need this, because at this point
I see no other satisfactory outcome, but I'm disappointed that we
failed to achieve something more ambitious in terms of memory
management (garbage collection in whatever form; gc or rc) and @nogc
users will lose a subset of the language.

I'm familiar with the world where some/most libraries aren't available
to me, because people tend to use the most convenient memory
management strategy by default, and that is incompatible with my
environment.
That is the world we will have in D. It's 'satisfactory', ie, it's
workable for me and my people, but it's not ideal; it's a lost
opportunity, and it's disappointing. Perhaps I've just been
unrealistically hopeful for too long?

Perhaps it will fall to the allocator API to save us from this
situation I envision, but I don't have a picture for that in my head.
It feels like it will probably be awkward and complicated to me
however I try and imagine the end product. The likely result of that
will be people not using it (just sticking with default GC allocation)
unless they are compelled by a high level of experience, or by their
intended user base, again suggesting a separation into 2 worlds.

I hope I'm completely wrong. Really!


>> The fact is, people who are capable of approaching this problem in
>> terms of actual code will never even attempt it until there's
>> resounding consensus that it's worth exploring.
>
>
> Could you please let me know how we can rephrase this paragraph on
> http://wiki.dlang.org/Vision/2015H1:
>
> =============
> Memory Management
>
> We aim to improve D's handling of memory. That includes improving the
> garbage collector itself and also making D eminently usable with limited or
> no use of tracing garbage collection. We aim to make the standard library
> usable in its entirety without a garbage collector. Safe code should not
> require the presence of a garbage collector.
> =============
>
> Could you please let me know exactly what parts you don't understand or
> agree with so we can change them. Thanks.

I understand what it says, and I generally agree with it.
I agree that @nogc will give us a C-like foundation to work outwards
from, and that is a much better place than where we are today, so I
have come to support the direction.

I wouldn't complain if efficient RC was on the roadmap, but I agree
it's outside the scope for the immediate future.

If it were to be said that I 'disagree' with some part of it, which
isn't true, it would be that it risks leading to an end that I'm not
sure is in our best interest; we will arrive at C vs C++.
As I said above, and many many times in the past, I see the @nogc
effort leading to a place where libraries are firmly divided between 2
worlds. My criticisms of that kind have never been directly addressed.

My suspicion is that this is mainly motivated by the fact it is the
simplest and lowest-level path, it will give the best low-level
building-blocks, and I think that's probably a good thing. But I can
also imagine more ambitious paths, like replacing the GC with
ambitious ARC implementation as the OP raised (if it's workable, I'm
not convinced either way), which would require massive R&D and almost
certainly lead to some radical changes. I think resistance is
predicated mainly on a rejection of such radical changes, and that's
fair enough, but is that rejection of radical change worth dividing D
into 2 worlds like C/C++? I don't know of any discussion on this value
tradeoff... not to mention, the significant loss of language features
to the @nogc camp.

I'm not asking for any changes. I just gave an opinion to the OP. I
can see there is RC work going on now, that's good. I expect (well, am
hopeful) it will eventually lead to some form of ARC. We'll see.


Re-reading my first 8 posts, I still feel they are perfectly
reasonable. I'm not sure where exactly it is that I started 'a thing',
but my feeling is it was only when you gave a long and somewhat
aggressive reply, and then made a cheap attack on my character, that I
tend to reply in kind.
I also feel like I'm forced to reply, to every point, otherwise I
proliferate this caricature you're prescribing to me (where I
disappear when it gets 'hard', or rather, more time consuming than I
have time for). Which is often true; it does become more time
consuming than I have time for... does that mean I'm not entitled to
input on this forum?
I'll return to my hole now.