Idea #1 on integrating RC with GC

[Paulo Pinto]

On Thursday, 6 February 2014 at 02:31:19 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 6 February 2014 at 00:42:20 UTC, Andrei 
> Alexandrescu
> wrote:
>> One school of thought seems to be that D should be everything 
>> it is today, just with reference counting throughout instead 
>> of garbage collection. One build flag to rule them all would 
>> choose one or the other.
>>
>> One other school of thought (to which I subscribe) is that one 
>> should take advantage of reference counting where appropriate 
>> within a GC milieu, regardless of more radical RC approaches 
>> that may be available.
>
> The third school of thought is that one should be able to have
> different types of allocation schemes without changing the 
> object
> type, but somehow tie it to the allocator and if needed to the
> pointer type/storage class.
>
> If you allocate as fully owned, it stays owned. If you allocate 
> as shared with immediate release (RC) it stays shared. If you 
> allocate as shared with delayed collection (GC) it stays that 
> way.
>
> The RC/GC metadata is a hidden feature and
> allocator/runtime/compiler dependent component. Possibly you
> won't have GC or RC, but one pure GC runtime, one integrated
> RC/GC runtime, one pure ARC runtime, one integrated ARC/GC
> runtime etc. That's probably most realistic since the allocation
> metadata might be in conflict.
>
> You should be able to switch to the runtime you care about if
> needed as a compile time switch:
>
> 1. Pure Owned/borrowed: hard core performance, OS level
> development
>
> 2. Manual RC (+GC): high throughput, low latency
>
> 3. ARC (+GC): ease of use, low throughput, low latency
>
> 4. GC: ease of use, high throughput, higher latency, long lived
>
> 5. Realtime GC
>
> 6. ??
>
> I see no reason for having objects treated differently if they 
> are "owned", just because they have a different type of 
> ownership. If the function dealing with it does not own it, but 
> borrows it, then it should not matter. The object should have 
> the same layout, the ownership/allocation metadata should be 
> encapsulated and hidden.
>
> It is only when you transfer ownership that you need to know if 
> the object is under RC or not.  You might not  even want to use 
> counters in a particular implementation, maybe it is better to 
> use a linked list in some scenarios. "reference counting" is a 
> misnomer, it should be called "ownership tracker".
>
> The current default is that all pointers are shared. What D 
> needs is defined semantics for ownership. Then you can start 
> switching one runtime for another one and have the 
> compiler/runtime act as an efficient unit.

That won't play ball with third party libraries distributed in 
binary form.

This is one of the reasons why Apple's Objective-C GC failed.

--
Paulo