Ruling out arbitrary cost copy construction?

[Michel Fortin]

On 2010-10-06 16:19:45 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 10/6/10 14:09 CDT, Michel Fortin wrote:
>> The most problematic thing with reference-counted memory is that the GC
>> can call your struct's destructor from any thread which can cause
>> low-level races if the reference counter isn't manipulated with atomic
>> operations. And atomic operations slow things down, are you sure you
>> want to force this in BigInt?
> 
> The GC shouldn't be able to destroy things naively concurrently with 
> other threads. Currently all threads are frozen; I'm not sure whether a 
> frozen thread commits its writes, so that needs to be verified.

My current understanding (after looking at the GC's code) is that all 
threads are frozen during the mark phase, while it builds a list of 
objects to destroy. Then, threads are unfrozen while objects on the 
list are destroyed.

And even if all threads were frozen while objects are being destroyed, 
how do you know that one thread hasn't been frozen in the middle of a 
read-modify-write operation with reference counter? Bad timing could 
result in an invalid reference count. Again, you'd need an atomic 
operation to make sure the GC doesn't stop a thread in the middle of a 
read-modify-write.

Another solution would be to make the GC call destructors in the same 
thread that owns the object, but that would require thread-local memory 
pools.

Related is the discussion for this bug:
<http://d.puremagic.com/issues/show_bug.cgi?id=4621>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/