It does. D offers a mix of manual and gc allocating, and the people who want higher overall performance lean towards more manual. Any penalty that applies to pointer code then gets amortized against less use of the gc.

It's a different tradeoff if the languages primary allocation scheme is GC.

The obvious approach to that issue is to support garbage-collected objects as a special address space within the program. You could use normal read-only pointers to address these, but write pointers to them would be specialized and incur that memory barrier overhead.

There's an API call into the GC that does just that, tell you if it points into the GC pool or not.

Unfortunately, it's not fast enough.

Why does this have to be a runtime check? Perhaps the compiler could optimize pointer writes that can be proven not to affect garbage-collected objects, by dispensing with the memory barrier overhead for those.