Want reasonable reference counting? Disable automatic sharing of immutable

Steven Schveighoffer schveiguy at gmail.com
Fri Nov 12 23:07:02 UTC 2021


On 11/12/21 5:07 PM, Andrei Alexandrescu wrote:
> On 2021-11-12 14:22, Steven Schveighoffer wrote:
>> I'm not going to fight for this, I just wanted to bring it up. But I 
>> think it's pointless to try for reference counting of immutable data 
>> (the long RCSlice thread), when it's obviously not immutable data.
> 
> I'm not so sure. I mean no laws of physics or even of typing are broken.
> 
> Consider as a baseline the following: there is a global synchronized 
> hashtable mapping pointers to objects to pointers to reference counters. 
> The table is obviously mutable. Whenever a reference to some piece of 
> data is copied around, a function gets called that looks up the pointer 
> to the reference count and increments it. Depending on type, the 
> increment is interlocked or not.

I'm well aware of that concept. See this post I made from 2008 (!): 
https://forum.dlang.org/post/fsth4a$79l$1@digitalmars.com

The problem is of course that this is not pure. As long as you don't 
need pure reference counting, it's a possible solution.

If you do need pure reference counting, this mechanism *cannot* be used, 
even if it's not technically accessing a global. I don't care what 
tricks you want to pull, the optimizer is going to bite you for it.

I'm skeptical that even normal optimizations outside of pure won't bite 
you on this either.

>> The only solution is to make it not mean the same as immutable does 
>> now (i.e. possibly shared). The fact that `shared(immutable)` would 
>> mean the same thing as `immutable` does now is a path forward, but I 
>> can understand if nobody wants to do that. I happen to think most 
>> cases people are not sharing their immutable data, just like they 
>> mostly aren't sharing thread-local data.
> 
> Though that may be a solution, I'm not sure it's the only solution. I 
> can tell it's an expensive enough solution (in terms of changes to the 
> language and/or broken code) that it warrants looking for another.

Understandable, altering a fundamental rule for immutable is definitely 
not the first choice I would have either.

-Steve


More information about the Digitalmars-d mailing list