radical ideas about GC and ARC : need to be time driven?

[via Digitalmars-d]

On Thursday, 15 May 2014 at 07:27:41 UTC, Kagamin wrote:
> On Wednesday, 14 May 2014 at 09:39:01 UTC, Marc Schütz wrote:
>> RC is done by the object itself, so by definition it knows its 
>> own type, while the GC needs to be told about the type on 
>> allocation. AFAIK there is ongoing work to make this 
>> information available for non-class types.
>
> If you can unify RC on binary level for any type, GC can use 
> that unification too: when you allocate the object, you has its 
> type and can setup necessary structures needed to call the 
> destructor.

Exactly.

>
>> Well, it cannot be made 100% reliable by principle. That's 
>> just an inherent property of tracing GCs. The question is, can 
>> we define which uses of destructors are "safe" in this sense 
>> and which ones are not, and ideally find ways to detect unsafe 
>> uses at compile time... That's very much in the spirit of D: 
>> Something that looks right, should be right. If it is not, it 
>> should be rejected by the compiler.
>
> Does this suggest that if you slip a type with destructor into 
> your code, it will force everything to be refcounted?

Hmm... that's probably too strict. There are often non-critical 
resources that need to be released on destruction, like a 
hypothetical String class which owns it's data and which is 
itself allocated on the GC heap, because we don't need eager 
destruction for it. We'd want the data buffer to be released as 
soon the String object is destroyed. This buffer might even be 
allocated on the C heap, so we cannot rely on the garbage 
collector to clean it up later. Is that a job for a finalizer?