More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/1/14, 3:10 AM, monarch_dodra wrote:
> On Thursday, 1 May 2014 at 01:04:08 UTC, Steven Schveighoffer wrote:
>>> That means classes that need cleanup (either directly or by having
>>> fields that are structs with destructors) would need to garner that
>>> by other means, such as reference counting or manual. We're
>>> considering deprecating ~this() for classes in the future.
>>
>> So essentially, any class with a dtor needs reference counting? How
>> does one clean up a cycle of them?
>
> Yeah, what he said. This has me very worried. Making cycles is actually
> incredibly easy. Any "inteligently" implemented "node-based" data
> structure, implemented with classes, such as a linked list, a tree or a
> graph, is virtually guaranteed to have a cycle somewhere...

In my experience classes with destructors are simpler (files, 
sockets)... Lists, trees, and graphs tend to be in-memory objects. But 
of course this is just speculation.

> *Or*
>
> is the idea that reference counting only works for finalization, but the
> memory is still managed by the GC? In that case, the destructors would
> leak, but the memory still be released?
>
> That's still bad, of course, but not "as" bad...

Yah, that would be the case. Essentially we're talking about making the 
entire GC heap passive.


Andrei