At

https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d

I've implemented a pointer-only version of Variant called VariantPointer.

I plan to use it to construct light-weight polymorphism in trie containers for D I'm currently writing.

VariantPointer uses the top N-bits (N currently 8) to encode the type pointed to be the untyped-pointer encoded in the 64-N bits lower bits.

My question is:

It safe to assume that `typeBits` most significant bits of a pointer on a 64-bit system are always zero?

Note that I didn't want to use the lower bits because I'm currently unsure whether I need to represent stack-pointers aswell.

On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote:
> At
>
> https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d

Further:

What to do with fact that the GC will fail to scan VariantPointers?

Can the GC be tweaked to mask out the type bits before scanning?

On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote:
> At
>
> https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d
>
> I've implemented a pointer-only version of Variant called VariantPointer.
>
> [...]
>
> It safe to assume that `typeBits` most significant bits of a pointer on a 64-bit system are always zero?
>
> Note that I didn't want to use the lower bits because I'm currently unsure whether I need to represent stack-pointers aswell.

I'm very sure that there is no obligation for the OS to not issue a stack of memory starting at addresses near the limit of a 64-bit system. Thus, you can't count on it 100% of the time, though it is so rare as far as I know, that a simple enforce() for checking that the upper bits are clear should be acceptable. Though, it may perhaps be unusable in a few decades time, if you still care then.

I can't answer your second question.

On Wednesday, 20 April 2016 at 14:36:54 UTC, Nordlöw wrote:
> On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote:
>> At
>>
>> https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d
>
> Further:
>
> What to do with fact that the GC will fail to scan VariantPointers?
>
> Can the GC be tweaked to mask out the type bits before scanning?

core.memory.GC.setAttr can set attributes for a block of memory, with which you can set the attribute NO_SCAN, which as it implies, forces that no scan be done in the particular block of memory.
This can be used to insure that the GC doesn't mark blocks not alive as alive.
Then, use GC.addRoot with the pointer to your actual data, with the typeinfo bits cleared, passed as a parameter, to add an internal pointer inside the GC itself to the data, so that is considered live until removeRoot is called on the same pointer. addRoot and removeRoot can be put into this and ~this, respectively.

On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote:
> At
>
> https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d
>
> I've implemented a pointer-only version of Variant called VariantPointer.
>
> I plan to use it to construct light-weight polymorphism in trie containers for D I'm currently writing.
>
> VariantPointer uses the top N-bits (N currently 8) to encode the type pointed to be the untyped-pointer encoded in the 64-N bits lower bits.
>
> My question is:
>
> It safe to assume that `typeBits` most significant bits of a pointer on a 64-bit system are always zero?
>
> Note that I didn't want to use the lower bits because I'm currently unsure whether I need to represent stack-pointers aswell.

Linux seems to reject mmap requests at or above 0x80000000000, though the vsyscall page is at 0xffffffffff600000 near the end of the virtual memory space. So it might work on Linux.

As for the GC, you're probably out of luck. Adding a global mask option is unlikely to work well if multiple libraries use it.

On Wednesday, 20 April 2016 at 16:08:32 UTC, Lass Safin wrote:
> core.memory.GC.setAttr can set attributes for a block of memory, with which you can set the attribute NO_SCAN, which as it implies, forces that no scan be done in the particular block of memory.
> This can be used to insure that the GC doesn't mark blocks not alive as alive.

Is this needed

- *only* for regions allocated with GC.malloc or
- *also* for memory allocated with non malloc/calloc/realloc?

On Wednesday, 20 April 2016 at 18:40:58 UTC, Alex Parrill wrote:
> As for the GC, you're probably out of luck. Adding a global mask option is unlikely to work well if multiple libraries use it.

So we need an optional block-local mask then! ;)

On Wednesday, 20 April 2016 at 20:07:31 UTC, Nordlöw wrote:
> On Wednesday, 20 April 2016 at 16:08:32 UTC, Lass Safin wrote:
>> core.memory.GC.setAttr can set attributes for a block of memory, with which you can set the attribute NO_SCAN, which as it implies, forces that no scan be done in the particular block of memory.
>> This can be used to insure that the GC doesn't mark blocks not alive as alive.
>
> Is this needed
>
> - *only* for regions allocated with GC.malloc or
> - *also* for memory allocated with non malloc/calloc/realloc?

NO_SCAN should probably be set for all types of memory blocks. I don't even know if the GC actually scans mallocated memory in the first place.

On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote:
> https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d

Moved here:

https://github.com/nordlow/phobos-next/blob/master/src/variant_ex.d