On 6/30/2013 7:36 PM, Steven Schveighoffer wrote:
> On Jun 30, 2013, at 10:26 PM, Walter Bright wrote:
>
>> On 6/30/2013 5:25 PM, Steven Schveighoffer wrote:
>>> On Jun 30, 2013, at 8:18 PM, Walter Bright wrote:
>>>
>>>> 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.
>>> I think you didn't understand what Michel was saying.
>>>
>>> Take for example:
>>>
>>> A->B->C->A
>>>
>>> this is a cycle. Imagine that nobody else is pointing at A, B or C. Fine.
The GC starts to collect this cycle.
>>>
>>> But let's say that D is not being collected *AND* B has a reference to D.
>>>
>>> B could be getting destroyed in one thread, and decrementing D's reference
count, while someone else in another thread is incrementing/decrementing D's
reference count.
>>>
>>> I agree that RC optimally is thread-local. But if you involve the GC, then
ref incs and decs have to be atomic.
>> This is actually a problem right now with the GC, as destructors may be run
in another thread than they belong in. The situation you describe is not worse
or better than that, it's the same thing. The solution is to run the destructors
in the same thread the objects belong in.
> I think that's a tall order presently. For instance, on linux, the threads
are all stopped using a signal. It's a very bad idea to run destructors in a
signal handler.
>
> What it seems like you are saying is that a prerequisite for ref counting is
to have thread-local GC working. If that is the case, we need to start a
thread-local GC "thread" before this goes any further.
Not really. This doesn't make anything worse. Also, the proposed solution to
this issue is to post the "destruct" list to the appropriate thread, and that
thread runs it next time it calls the GC.
>
>>> I don't think this is that bad. iOS on ARM which has terrible atomic
primitives uses atomic reference counts.
>> It's bad. ARM is not the only processor out there.
>
> Pragmatically, I think if D targets x86 variants and ARM, it is well-situated
in the mainstream of existing devices. Yes, it would be nice if it could target
other obscure platforms, but if we are talking ref counting works poorly on
those, I don't think we are any worse off than today. Note that we can keep the
options open, and implement atomic RC now without many headaches.
>
We don't need to require atomic RC for these.
