draft proposal for ref counting in D

[Walter Bright]

On 6/30/2013 4:35 PM, Michel Fortin wrote:
 > Le 30-juin-2013 à 18:11, Walter Bright  a écrit :
 >
 >> On 6/30/2013 3:05 PM, Michel Fortin wrote:
 >>> Le 2013-06-30 à 16:32, Walter Bright  a écrit :
 >>>
 >>>> Amended as:
 >>>>
 >>>> 6. If a class or struct contains RC fields, calls to Release() for those 
fields will
 >>>> be added to the destructor, and a destructor will be created if one 
doesn't exist already.
 >>>> Release() implementations should take care to not destroy objects that are 
already destroyed,
 >>>> which can happen if the objects are allocated on the GC heap and the GC 
removes a cycle of
 >>>> refcounted objects.
 >>> Good advice. But... how do you implement that? For one thing, I doubt 
there's an API in the GC you can query for deleted objects, and if there was 
it'd be inefficient to call it for every call to Release. And also, will a 
virtual call to a function of a destroyed object work in the first place? It all 
seems quite fragile to me.
 >> The GC doesn't actually delete anything while it is doing a collection 
cycle. So the refcount could simply be checked.
 >
 > ... checked and decremented, and if it reaches zero in the thread the GC is 
currently running then it doesn't have to delete the object as, in theory, it 
should be destructed as part of the same run. Ok, I get it now.
 >
 > You should add a requirement that the reference counter be atomic because the 
GC can run in any thread and you still need to decrement counters of referenced 
objects in destructor.

I very much want to avoid requiring atomic counts - it's a major performance 
penalty. Note that if the GC is reaping a cycle, nobody else is referencing the 
object, so this should not be an issue.

 >
 > Honestly, I think it'd be much easier if the runtime provided its own base 
object you could use for reference counting with the GC to collect cycles. The 
provided implementation could rely on internal details of the GC since both 
would be part of druntime. There isn't much room for alternate implementations 
when the GC is involved anyway.
 >