Safe reference counting cannot be implemented as a library

[Manu via Digitalmars-d]

On 28 October 2015 at 11:13, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 10/27/2015 11:10 AM, deadalnix wrote:
>>
>> I've made the claim that we should implement reference counting as a
>> library
>> many time, so I think I should explicit my position. Indeed, RC require
>> some
>> level a compiler support to be safe. That being said, the support does not
>> need
>> to be specific to RC. On fact, my position is that the language should
>> provide
>> some basic mechanism on top of which safe RC can be implemented, as a
>> library.
>
>
>
> It's not just safety. If the compiler knows that reference counting is going
> on, it can potentially elide a lot of the overhead. If it is faced with an
> arbitrary library solution, it only has a worm's eye view of it, and cannot
> do higher level optimizations.

I just want to drop in that I strongly feel both points here, they are
not at odds. I've been arguing for years now that D needs effective
escape analysis, this will allow all sorts of safe allocation and
lifetime patterns; and while it may enable some improved library
solutions to refcounting, I think the key advantage is actually
related to making better and safe use of stack allocation. I think
that is a much better focus when considering the need for
comprehensive escape analysis tools.
That has little to do with the language also benefiting from RC
primitives such that the compiler is able to do a quality job of
optimising ref-counting, which is a spectacularly prevalent pattern,
particularly so when used in conjunction with libraries such that the
inc/dec functions are opaque indirect calls into some foreign lib and
can't be optimised (this is the majority case in my experience). If
they can't be wrapped by a language primitive that it knows can
optimise this particular calling pattern, then the compiler has no
power to optimise such opaque calls at all.

As an anecdote, since I operate almost exclusively via practical
experience; my current project would heavily benefit from both, and
they would each contribute to a strong case for migration to D. These
2 issues alone represent, by far, the greatest trouble we face with
C++ currently.
RC is okay-ish in C++11 (with rval references), although it could be
much better, for instance, the type mangling/wrapping induced by this
sort of library solution always leads to awkward situations, ie,
'this' pointer in a method is not an RC object anymore! Methods can't
give out pointers to themselves (ie, signaling events where it's
conventional to pass a 'sender' to the subscribers). Pretty massive
fail!
But what we completely fail at is making good use of stack allocation;
requiring conservative fallback to heap allocations because we have no
proof mechanism for containing temporary ownership. We need expressive
escape analysis.

This is a very heavily object orientated codebase, rife with shared
pointers, with a strong focus on the external API and user
extensibility. Focus on the public API implies conservative allocation
habits; ie, RC is prevalent because we don't want to place complex
restrictions on users, and we must also be safe. If we has an
effective escape analysis mechanism, we would gain a lot of
opportunities to revert RC to stack allocations because we can
statically prove via the API that the user won't escape pointers.

The program consists of a typical hierarchical ownership structure, an
arbitrarily shared generalised resource pool, a highly interactive
scene graph with runtime datasets scaling to 10s of gigabytes, and a
ridiculously abstract API's (lots of painful C++ meta-magic). It is
also realtime. GC was considered and rejected on the premise that it
is realtime, and operates on truly gargantuan working datasets.
It's the most ambitious thing I've ever written, and I am dying inside
a little bit more every single day that I remain stuck with C++. I
want to start writing front-end plugin code in D as soon as possible,
which means, at very least, comprehensive RC interaction.