More radical ideas about gc and reference counting

[deadalnix via Digitalmars-d]

On Wednesday, 30 April 2014 at 22:08:23 UTC, John Colvin wrote:
> I don't think I fully understand.
>
> Either all RC changes for a given type need to be atomic or 
> none do, and that information is given by the type (everything 
> that is immutable/const/shared). I don't see any feasible way 
> of escaping this, or any advantage to a runtime convention like 
> the odd/even trick above.

If you CPU is decent you have some cache coherency protocol in 
place. This won't ensure that thing appears sequentially 
consistent, but you don't care here.

You can proceed as follow in pseudo assembly :

count = load count_addr
need_atomic = count & 0x01
brtr atomic
count = count + 2
store count count_addr
br follow_up

atomic:
atomic_add count_addr 2

follow_up:
// Code after increment goes here

Note that is working as count may not be the correct number in 
case of sharing, but will always have the same parity, so even 
reading the wrong value will make you branch properly and the 
value of count is not used to increment in the atomic block.

I'm not happy with this solution, because:
  - You still have an atomic in there, and the compiler can't 
remove it. This reduce greatly the capability of the compiler to 
optimize. For instance, the compiler cannot optimize away 
redundant pairs of increment/decrement.
  - You have a branch in there. Atomic are expensive, but branch 
as well. Especially since both are storing (and one atomically), 
so it can't be speculated.
  - If we start using that all over the place, the codegen will 
ends up being quite fat. That means less friendly cache behavior.

That odd/even solution surely works, but ultimately do not solve 
the issue: if you want full speed, you'll have to provide both a 
const and a mutable version of the code, which defeat the purpose 
of const. Note that the exact same issue exists with inout.