GC: Understanding potential sources of false pointers
thedeemon via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu Apr 20 01:00:59 PDT 2017
On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky
> 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
> 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
> 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
More information about the Digitalmars-d-learn