Idea #1 on integrating RC with GC

[Andrei Alexandrescu]

On 2/5/14, 12:23 PM, Michel Fortin wrote:
> On 2014-02-05 18:26:38 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 2/5/14, 7:23 AM, Michel Fortin wrote:
>>> I don't think it makes much sense. ARC when used for D constructs should
>>> be treated an alternate GC algorithm, not a different kind of pointer.
>>
>> Why? The RC object has a different layout, so it may as well have a
>> different type.
>
> Well, it depends on your goal. If your goal is to avoid the garbage
> collector, you need all language constructs to use ARC. Having a single
> type in the language that relies on the GC defeats the purpose. What you
> want is simply to replace the current GC with another implantation, one
> that uses ARC. It shouldn't affect user code in any way, it's mostly an
> implementation detail (managed by the compiler and the runtime).
>
> If your goal is to have a deterministic lifetime for slices in some
> situations, then RCSlice as you proposes it is fine. That said, with a
> library type you'll have a hard time making the optimizer elide
> redundant increment/decrement pairs, so it'll never be optimal. I'm also
> not sure there's a lot of use cases for a deterministic slice lifetime
> working side by side with memory managed by the current GC.
>
> To me it seems you're trying to address a third problem here: that
> people have complained that Phobos relies on the GC too much. This comes
> from people who either don't want the GC to pause anything, or people
> who want to reduce memory allocations altogether. For the former group,
> replacing the current GC with an ARC+GC scheme at the language level,
> with the possibility to disable the GC, will fix most of Phobos (and
> most other libraries) with no code change required. For the later group,
> you need to make the API so that allocations are either not necessary,
> or when necessary provide a way to use a custom an allocator of some sort.

I want to make one positive step toward improving memory allocation in 
the D language.

Andrei