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

via Digitalmars-d digitalmars-d at puremagic.com
Wed May 14 02:38:59 PDT 2014


On Wednesday, 14 May 2014 at 06:44:44 UTC, Kagamin wrote:
> On Tuesday, 13 May 2014 at 17:53:10 UTC, Marc Schütz wrote:
>> Currently it isn't, because the GC sometimes lacks type 
>> information, e.g. for dynamic arrays.
>
> Will RC be guaranteed to always have type information? If it 
> can, why GC can't? If it can't, what's the difference?
>

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.

> On Tuesday, 13 May 2014 at 18:07:42 UTC, Marc Schütz wrote:
>> It's not (memory) unsafe because you cannot delete live 
>> objects accidentally, but it's "unsafe" because it leaks 
>> resources. Imagine a file object that relies on the destructor 
>> closing the file descriptor. You will quickly run out of FDs...
>
> It's the same situation in .net, where GC doesn't guarantee 
> calling finalizers of arbitrary classes in all scenarios, they 
> have to be special classes like SafeHandle, and resource 
> handles are usually implemented deriving from SafeHandle. Is it 
> constructive to require D GC be better than .net GC?

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.


More information about the Digitalmars-d mailing list