www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - VariantPointer

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Apr 20 2016
next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Apr 20 2016
parent reply Lass Safin <lasssafin gmail.com> writes:
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.
Apr 20 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Apr 20 2016
parent Lass Safin <lasssafin gmail.com> writes:
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.
Apr 21 2016
prev sibling next sibling parent Lass Safin <lasssafin gmail.com> writes:
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.
Apr 20 2016
prev sibling next sibling parent reply Alex Parrill <initrd.gz gmail.com> writes:
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.
Apr 20 2016
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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! ;)
Apr 20 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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
Apr 30 2016