Thread overview
precise gc?
Nov 10, 2012
eskimo
Nov 10, 2012
Nick Sabalausky
Nov 11, 2012
Thiez
Nov 11, 2012
Kapps
Nov 11, 2012
eskimo
Nov 11, 2012
eskimo
Nov 11, 2012
David Nadlinger
Nov 11, 2012
eskimo
November 10, 2012
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

November 10, 2012
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.

November 11, 2012
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...
November 11, 2012
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.
November 11, 2012
> 
> 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!

November 11, 2012
> 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?

November 11, 2012
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
November 11, 2012
> 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.)