Idea #1 on integrating RC with GC

[Manu]

On 6 February 2014 06:23, Michel Fortin <michel.fortin at michelf.ca> 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.


This.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140206/b9436009/attachment.html>