Idea #1 on integrating RC with GC

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

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.