Re: GC: Understanding potential sources of false pointers

2017-04-25 Thread Kagamin via Digitalmars-d-learn 

They are for static data an thread-local storage.

Re: GC: Understanding potential sources of false pointers

2017-04-24 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-learn 

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. :/

Re: GC: Understanding potential sources of false pointers

2017-04-22 Thread Kagamin via Digitalmars-d-learn 
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.

Re: GC: Understanding potential sources of false pointers

2017-04-20 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-learn 

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.

Re: GC: Understanding potential sources of false pointers

2017-04-20 Thread Kagamin via Digitalmars-d-learn 

https://issues.dlang.org/show_bug.cgi?id=15723

Re: GC: Understanding potential sources of false pointers

2017-04-20 Thread thedeemon via Digitalmars-d-learn 
On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky 
(Abscissa) wrote:

According to :

"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).