www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC: Understanding potential sources of false pointers

reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Apr 19
next sibling parent thedeemon <dlang thedeemon.com> writes:
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).
Apr 20
prev sibling parent reply Kagamin <spam here.lot> writes:
https://issues.dlang.org/show_bug.cgi?id=15723
Apr 20
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/20/2017 09:00 AM, Kagamin wrote:
 https://issues.dlang.org/show_bug.cgi?id=15723
Hmm, so apparently embedded data (even if it's from a C lib) can also be a source of false pointers. Thanks, good to know.
Apr 20
parent reply Kagamin <spam here.lot> writes:
On Thursday, 20 April 2017 at 20:26:06 UTC, Nick Sabalausky 
(Abscissa) wrote:
 (even if it's from a C lib)
Same for D: .rdata is fine, but afaik you have only strings there, the rest - .data, .bss, .tls will suffer the same issue.
Apr 22
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/22/2017 08:56 AM, Kagamin wrote:
 .rdata is fine, but afaik you have only strings there, the rest - .data,
 .bss, .tls will suffer the same issue.
I don't know anything about the various object file sections. :/
Apr 24
parent Kagamin <spam here.lot> writes:
They are for static data an thread-local storage.
Apr 25