Smart pointers instead of GC?

[Adam Wilson]

On Mon, 03 Feb 2014 18:14:36 -0800, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:

> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>> 1. RC imposes a time overhead on mutators in order to manipulate the  
>> counter.
>
> Usually you just do a retain() when your thread attain ownership (at the  
> root of the call tree). If you use embedded counters you most likely  
> want the data in the cache anyway, but the cacheline is made dirty. So  
> it cost you a write back. That affects reads of small objects more than  
> writes.
>
> (The C++ implementation does not use embedded counters.)
>

There are many more ways to modify the count than a thread.

>> 2. Both the counter manipulation and pointer load/store operations MUST  
>> be atomic to prevent races.
>
> Not with transactional memory. You revert to locking, and you probably  
> want that kind of synchronization anyway if you run multi threaded.
>

Transactional memory incurs a massive perf penalty beyond even what a lock  
would. You might be able to do better than a lock with Intel's TSX, but  
that is brand new, available on Haswells only, and even then only the  
high-end models. I doubt you'll be able to sell TM-ARC to perf conscience  
users as the perf will most likely be much worse than a GC for the next  
decade.


-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator