In Dicebot's DConf talk he mentioned that it is possible to use the top 16 bits for tagging pointers and the associated risks.

Regarding the GC not seeing a pointer if the top 16 bits are used, whats to stop us from changing the GC to (or adding an option to) ignore those bits when checking?

I imagine that it would cause a lot more false pointers, but when we get precise GC that problem would go away.

On Saturday, 7 May 2016 at 06:08:01 UTC, Nicholas Wilson wrote:
> In Dicebot's DConf talk he mentioned that it is possible to use the top 16 bits for tagging pointers and the associated risks.
>
> Regarding the GC not seeing a pointer if the top 16 bits are used, whats to stop us from changing the GC to (or adding an option to) ignore those bits when checking?
>
> I imagine that it would cause a lot more false pointers, but when we get precise GC that problem would go away.

The problem with this is, that its not future proof. Once the top 16-bits of a pointer get used D programs will suddenly stop working. So i think we shouldn't support that officially. If you really want to do that you can simply hack the scan routine of the gc in druntime yourself and ship with the hacked version.

On 05/06/2016 11:08 PM, Nicholas Wilson wrote:
> In Dicebot's DConf talk

That was deadalnix. :)

Ali

On Saturday, 7 May 2016 at 09:01:11 UTC, Ali Çehreli wrote:
> On 05/06/2016 11:08 PM, Nicholas Wilson wrote:
>> In Dicebot's DConf talk
>
> That was deadalnix. :)
>
> Ali

Touché.

Am Sat, 07 May 2016 12:02:07 +0000
schrieb Nicholas Wilson <iamthewilsonator@hotmail.com>:

> On Saturday, 7 May 2016 at 09:01:11 UTC, Ali Çehreli wrote:
> > On 05/06/2016 11:08 PM, Nicholas Wilson wrote:
> >> In Dicebot's DConf talk
> >
> > That was deadalnix. :)
> >
> > Ali
> 
> Touché.

Too many d's for the day. :) I agree with Benjamin, that we can't rely on the 16-bits being reserved forever.

I have a question about the lower 3 bits OTOH. The minimal GC allocation size is >= 8 bytes, right? I.e. if we set the lower 3 bits to 0b111, and the pointer points to a 4 byte structure, it will still be recognized as an internal pointer due to the overallocation.

-- 
Marco

On Saturday, 7 May 2016 at 12:32:53 UTC, Marco Leise wrote:
> Am Sat, 07 May 2016 12:02:07 +0000
> schrieb Nicholas Wilson <iamthewilsonator@hotmail.com>:
>
>> On Saturday, 7 May 2016 at 09:01:11 UTC, Ali Çehreli wrote:
>> > On 05/06/2016 11:08 PM, Nicholas Wilson wrote:
>> >> In Dicebot's DConf talk
>> >
>> > That was deadalnix. :)
>> >
>> > Ali
>> 
>> Touché.
>
> Too many d's for the day. :) I agree with Benjamin, that we can't rely on the 16-bits being reserved forever.
>
> I have a question about the lower 3 bits OTOH. The minimal GC allocation size is >= 8 bytes, right? I.e. if we set the lower 3 bits to 0b111, and the pointer points to a 4 byte structure, it will still be recognized as an internal pointer due to the overallocation.

You could have allocated an array, so that's a problem, you can only use 2 bits. taggedPointer will check for this at compile time.

But, yes, LSB are safe to use is you wrap it properly because it will be seen as an interior pointer.

On Saturday, 7 May 2016 at 06:08:01 UTC, Nicholas Wilson wrote:
> In Dicebot's DConf talk he mentioned that it is possible to use the top 16 bits for tagging pointers and the associated risks.
>
> Regarding the GC not seeing a pointer if the top 16 bits are used, whats to stop us from changing the GC to (or adding an option to) ignore those bits when checking?
>
> I imagine that it would cause a lot more false pointers, but when we get precise GC that problem would go away.

I would not rely on it *at all* actually, even now. I do not think it would make D portable to every system (let's not only consider x86 architecture).
We don't know how a system would choose to map physical memory and hardware devices to virtual memory.