• eskimo <jfanatiker gmx.at> Nov 10 2012
• Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> Nov 10 2012
• "Thiez" <thiezz gmail.com> Nov 10 2012
• "Kapps" <opantm2+spam gmail.com> Nov 10 2012
• eskimo <jfanatiker gmx.at> Nov 11 2012
• eskimo <jfanatiker gmx.at> Nov 11 2012
• "David Nadlinger" <see klickverbot.at> Nov 11 2012
• eskimo <jfanatiker gmx.at> Nov 11 2012

eskimo <jfanatiker gmx.at> writes:

Hey party people!

What is the current state? Is it enough to store a pointer in a
ptrdiff_t variable instead of a pointer for the GC to ignore it or is my
current trick of simply inverting its value required?

If the trick is required, is it safe? Are there memory models in use
where the inverted pointer value might also be in GC memory?

Thanks!

Robert

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 10 Nov 2012 23:17:41 +0100
eskimo <jfanatiker gmx.at> wrote:

 Hey party people!
 
 What is the current state? Is it enough to store a pointer in a
 ptrdiff_t variable instead of a pointer for the GC to ignore it or is
 my current trick of simply inverting its value required?
 


I'm not sure I understand why you would hide a pointer from the GC.

 Are there memory models in use
 where the inverted pointer value might also be in GC memory?
 


Yes, that can happen in 32-bit.

"Thiez" <thiezz gmail.com> writes:

On Saturday, 10 November 2012 at 22:52:56 UTC, Nick Sabalausky 
wrote:
 On Sat, 10 Nov 2012 23:17:41 +0100
 eskimo <jfanatiker gmx.at> wrote:

 Hey party people!
 
 What is the current state? Is it enough to store a pointer in a
 ptrdiff_t variable instead of a pointer for the GC to ignore 
 it or is
 my current trick of simply inverting its value required?
 


 I'm not sure I understand why you would hide a pointer from the 
 GC.


It might happen by accident, like when you're doing something 
'clever' like using them good old fashioned xor-linked lists...

"Kapps" <opantm2+spam gmail.com> writes:

On Saturday, 10 November 2012 at 22:52:56 UTC, Nick Sabalausky 
wrote:
 On Sat, 10 Nov 2012 23:17:41 +0100
 eskimo <jfanatiker gmx.at> wrote:

 Hey party people!
 
 What is the current state? Is it enough to store a pointer in a
 ptrdiff_t variable instead of a pointer for the GC to ignore 
 it or is
 my current trick of simply inverting its value required?
 


 I'm not sure I understand why you would hide a pointer from the 
 GC.



For weak references mainly. For example, caching, weak event 
subscribers, and a fair few other things.

eskimo <jfanatiker gmx.at> writes:

 
 I'm not sure I understand why you would hide a pointer from the GC.


new std.signals implementation.
 
 Are there memory models in use
 where the inverted pointer value might also be in GC memory?
 


 Yes, that can happen in 32-bit.
 


easy. On the other hand especially because less space is wasted for
pointers on 32 bit, I can easily afford an extra variable to solve this
problem (kind of). Buah, I am starting to like 64 bit architectures ;-)

Thanks!

eskimo <jfanatiker gmx.at> writes:

 Yeah, you are right if all pointer bits are actually used it is far too
 easy. On the other hand especially because less space is wasted for
 pointers on 32 bit, I can easily afford an extra variable to solve this
 problem (kind of). 


I guess it is a pretty safe bet to assume that the lowest 65535
addresses in memory space (mask: 0x0000ffff) are not in GC memory?

"David Nadlinger" <see klickverbot.at> writes:

On Saturday, 10 November 2012 at 22:17:10 UTC, eskimo wrote:
 What is the current state? Is it enough to store a pointer in a
 ptrdiff_t variable instead of a pointer for the GC to ignore it


For a precise GC (as in the thread title) yes, but not for the 
current D GC.

 or is my
 current trick of simply inverting its value required?


You could use it, and come up with something else which also 
works on x86, etc., but I'd look into storing your weak reference 
(or whatever) in a page with the NO_SCAN attribute set. It will 
cause the GC to ignore it entirely.

David

eskimo <jfanatiker gmx.at> writes:

 You could use it, and come up with something else which also 
 works on x86, etc., but I'd look into storing your weak reference 
 (or whatever) in a page with the NO_SCAN attribute set. It will 
 cause the GC to ignore it entirely.


Thanks but that's no option for me, because I need the pointers, to be
ignored by the GC, to be in the same page as pointers which should not
be ignored. (Actually even in the same struct so they are really
neighbors.)