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.
