Le 27/12/2011 16:06, Andrei Alexandrescu a écrit :
On 12/27/11 5:43 AM, deadalnix wrote:
BTW, the plan is to have the same thread that constructed objects to
call their destructors; each thread would have a worklist of garbage
objects to destroy. The list can be reduced during calls to allocation
functions within each thread, and of course when the thread terminates.
Andrei
This is nice for thread local data, but does it make sense for
immuables/shared ?
Yes - when the GC reaps objects, they are past their useful lifetime so
their qualifiers are gone.
I'm 100% convinced that the GC should be aware of type qualifier. this
lead to many possible optimizations, and can be simply ignored when not
required.
I'm not sure this design is secure regrading GC. What happen if the
destructor of the RefCounted is called, (and will call dispose) and then
the payload is destructed. We have a risk of double destruction.
I'm not sure I understand the scenario.
OK, let's use an exemple, this is usually easier to understand.
You have something of type T with a destructor, and I'll call it
Patrick. And a RefCount struct pointing to it.
Let's consider the RefCount struct is on the heap and garbage collected.
Yes, I know, this is useless but possible so this have to be considered.
Now, the garbage collector run, and will mark both memory location to be
deleted : Patrick and the RefCount struct.
The RefCount, will call dispose on the something and the GC will call
dtor on Patrick. You'll never know in which order and so you can ends up
calling dispose on a destructed object. Or destruct something used in
the destructor in dispose. This is confusing.
Let's put in the fact that you cant to run thoses in the thread that
created them and you possibly ends-up with something quite confusing.
I think the dtor should be the only way to destruct something and not
the dispose method, and we have to ensure that the dtor is called by the GC.
