View mode: basic / threaded / horizontal-split · Log in · Help
November 10, 2012
precise gc?
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
Re: precise gc?
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
Re: precise gc?
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
Re: precise gc?
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
Re: precise gc?
> 
> 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
Re: precise gc?
> 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
Re: precise gc?
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
Re: precise gc?
> 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.)
Top | Discussion index | About this forum | D home