GC: Understanding potential sources of false pointers

[thedeemon via Digitalmars-d-learn]

On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky 
(Abscissa) wrote:
> According to <http://dlang.org/phobos/core_memory.html>:
>
> "Registers, the stack, and any other memory locations added 
> through the GC.addRange function are always scanned 
> conservatively."
>
> 1. Can that be safely assumed to be a canonical list of all 
> possible sources of false pointers?
>
> 2. What about memory allocated through language constructs such 
> as "new", append ("~"/"~="), closures, or any others I may be 
> forgetting? Is this memory always/never/sometimes set to 
> NO_SCAN? (I assume not "always", as that would be silly.) If 
> "sometimes", what are the conditions?
>
> A couple specific examples:
>
> 3. Are there any situations where a (for example) int[] or 
> long[] that is stored on the GC heap could lead to false 
> pointers?
>
> 4. Same question as #3, but if it's an array of structs, and 
> the struct type contains no members that are statically-typed 
> as pointers.

1. No, that's not the full list. Closures are indeed an important 
source of GC-allocated objects with pointers and often false 
pointers, for example.

2. With "new" compiler decides by the type whether the data may 
contain pointers, so arrays of numbers or arrays of structs with 
no pointers inside will be allocated as NO_SCAN.

3-4. As long as the compiler is sure about absence of pointers in 
allocated type, you're safe, I don't see a way for that data to 
become a source of false pointers (unless you fool the compiler 
with casts).