On 28 October 2015 at 11:13, Walter Bright via Digitalmars-d <[email protected]> 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.
