New pointer type for GC

Etienne via Digitalmars-d digitalmars-d at puremagic.com
Tue May 27 09:47:39 PDT 2014


On 2014-05-27 10:54 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Tuesday, 27 May 2014 at 14:42:34 UTC, Etienne wrote:
>> I think the GC is the future of D considering it's embedded to the
>> very core of the language, and compatibility with C code is ...
>> elementary.
>
> Well, but then I think you should be required to do manual tracking
> while it is being retained by C code. Basically a ref counter that keeps
> it marked reachable by the gc until released.
>
>> You slow the GC down by as much total memory there is in all threads
>> vs the avg in a thread, AND you remove parallel collection - by not
>> having the Thread ID in gc ptr references
>
> Not if you restrict the gc heap to a set of blocks. You can also keep
> thread info in the heap memoryblock.
>
>> behavior of a language if it stops its world. As a matter of fact, I
>> can't see any other way of fixing the GC than adding the Thread ID in
>> there :/
>
> By having multiple local GCs?


You're right, it's obviously easier to keep it as the same pointer 
syntax but hijack the stdlib malloc functions to forcibly go through the GC.

If the GC controls everything, you can keep the info in 8 byte pointers.

- The GC always returns an libc-incompatible pointer value
- Dereferencing should call the resolver from the GC to process it with 
the libc-compatible value (possibly just removing the last couple bytes)
- Sending a pointer through extern(C) should call the sanitizer which 
resolves the real pointer through the GC and sends that
- The last bytes of a pointer would contain thread ID for void** and 
poolID for void*
- This would only work on x64 platforms


More information about the Digitalmars-d mailing list