• eskimo (8/8) Nov 10 2012 Hey party people!
• Nick Sabalausky (4/13) Nov 10 2012 I'm not sure I understand why you would hide a pointer from the GC.
• Thiez (4/15) Nov 10 2012 It might happen by accident, like when you're doing something
• Kapps (4/15) Nov 10 2012 For weak references mainly. For example, caching, weak event
• eskimo (7/16) Nov 11 2012 Yeah, you are right if all pointer bits are actually used it is far too
• eskimo (2/6) Nov 11 2012 I guess it is a pretty safe bet to assume that the lowest 65535
• David Nadlinger (8/12) Nov 11 2012 For a precise GC (as in the thread title) yes, but not for the
• eskimo (4/8) Nov 11 2012 Thanks but that's no option for me, because I need the pointers, to be

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.

As already suggested by Kapps, for weak references. I need that for my
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.
 

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