Re: Interior pointers and fast GC

2017-01-22 Thread Shachar Shemesh via Digitalmars-d
On 21/01/17 17:30, Nick Treleaven wrote: On Saturday, 14 January 2017 at 15:30:42 UTC, Rainer Schuetze wrote: In addition, you need to lookup the pool anyway to figure out if the pointer points to non-managed memory (stack, global data, malloc'd memory). Makes me wonder about a GC'd language

Re: Interior pointers and fast GC

2017-01-22 Thread Chris Wright via Digitalmars-d
On Sun, 22 Jan 2017 06:44:47 +, Araq wrote: > On Sunday, 22 January 2017 at 06:28:35 UTC, Chris Wright wrote: >> On Sun, 22 Jan 2017 05:02:43 +, Araq wrote: >>> It's an O(1) that requires a hash table lookup in general because >>> allocations can exceed the chunk size and so you cannot

Re: Interior pointers and fast GC

2017-01-22 Thread deadalnix via Digitalmars-d
On Sunday, 22 January 2017 at 05:02:43 UTC, Araq wrote: It's an O(1) that requires a hash table lookup in general because allocations can exceed the chunk size and so you cannot just mask the pointer and look at the chunk header because it might not be a chunk header at all. Know any

Re: Interior pointers and fast GC

2017-01-21 Thread Araq via Digitalmars-d
On Sunday, 22 January 2017 at 06:28:35 UTC, Chris Wright wrote: On Sun, 22 Jan 2017 05:02:43 +, Araq wrote: It's an O(1) that requires a hash table lookup in general because allocations can exceed the chunk size and so you cannot just mask the pointer and look at the chunk header because

Re: Interior pointers and fast GC

2017-01-21 Thread Chris Wright via Digitalmars-d
On Sun, 22 Jan 2017 05:02:43 +, Araq wrote: > It's an O(1) that requires a hash table lookup in general because > allocations can exceed the chunk size and so you cannot just mask the > pointer and look at the chunk header because it might not be a chunk > header at all. Know any production

Re: Interior pointers and fast GC

2017-01-21 Thread Araq via Digitalmars-d
On Saturday, 21 January 2017 at 17:42:46 UTC, deadalnix wrote: 1. Split the heap in chunk of size n being a power of 2, say 4M. Align them 4M. 2. Find the chunk an alloc is part of in O(1) bu masking the lower bits (22 bits to mask in our 4M case). 3. Have a table of page descriptor in the

Re: Interior pointers and fast GC

2017-01-21 Thread deadalnix via Digitalmars-d
On Saturday, 14 January 2017 at 04:37:01 UTC, Chris Wright wrote: Unfortunately, given an interior pointer, you can't identify the base of its heap object in constant time. 1. Split the heap in chunk of size n being a power of 2, say 4M. Align them 4M. 2. Find the chunk an alloc is part of in

Re: Interior pointers and fast GC

2017-01-21 Thread Nick Treleaven via Digitalmars-d
On Saturday, 14 January 2017 at 15:30:42 UTC, Rainer Schuetze wrote: In addition, you need to lookup the pool anyway to figure out if the pointer points to non-managed memory (stack, global data, malloc'd memory). Makes me wonder about a GC'd language where each pointer is actually a member

Re: Interior pointers and fast GC

2017-01-14 Thread Rainer Schuetze via Digitalmars-d
On 14.01.2017 05:37, Chris Wright wrote: Interior pointers are a barrier to performant garbage collection. [...] * In a binary search tree, a prefix tree, or the like [...] The third strategy is O(log N) in the expected case and has similar data locality to the hashtable. Obviously, we