The "no gc" crowd

[Walter Bright]

On 10/9/2013 2:10 PM, Michel Fortin wrote:
> That's no different from the GC having to ignore those pointers when it does a
> scan. Just check it was allocated within the reference counted allocator memory
> pool, and if so adjust the block's reference counter, else ignore. There's a
> small performance cost, but it's probably small compared to an atomic
> increment/decrement.

When passing any dynamic array to a function, or most any assignment, the 
compiler must insert:

    (is pointer into gc) && (update ref count)

This is costly, because:

1. the gc pools may be fragmented, i.e. interleaved with malloc'd blocks, 
meaning an arbitrary number of checks for "is pointer into gc". I suspect on 64 
bit machines one might be able to reserve in advance a large enough range of 
addresses to accommodate any realistic eventual gc size, making the check cost 3 
instructions, but I don't know how portable such a scheme may be between 
operating systems.

2. the "update ref count" is likely a function call, which trashes the contents 
of many registers, leading to poor code performance even if that function is 
never called (because the compiler must assume it is called, and the registers 
trashed)

Considering that we are trying to appeal to the performance oriented community, 
these are serious drawbacks. Recall that array slicing performance has been a 
BIG WIN for several D users.