On 2014-05-27 10:54 AM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@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
