www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - precise gc?

reply 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
Nov 10 2012
next sibling parent 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.
Nov 10 2012
prev sibling next sibling parent "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...
Nov 10 2012
prev sibling next sibling parent "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.
Nov 10 2012
prev sibling next sibling parent 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!
Nov 11 2012
prev sibling next sibling parent 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?
Nov 11 2012
prev sibling next sibling parent "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
Nov 11 2012
prev sibling parent 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.)
Nov 11 2012