I've been looking at the GC and found that the main problem is that
there's no clear information about the pointers. At least smart pointers
have some info inside them but GC pointers are completely plain 4-8
bytes and nothing else.
The GC is very fast even if it needs to lookup this info but I believe
it wouldn't stay low-cpu in a 128 GB of RAM server with 3GB/s of memory
traffic with a wide range of memory segment sizes.
I think a decent proposal would be to
1- Introduce a new GC pointer type, e.g. a void' (its an apostrophee)
used also in classes which implicitely converts to void* by removing the
last bytes (which ontain the info). This pointer contains the Pool ID of
the underlying memory
2- For reference pointers to a GC pointer, &void' would add a thread ID
and magic number to better identify them during collection, and to avoid
stopping the whole world to dereference them
3- The space (4 bytes?) added by the new pointer size could be saved
with tighter storage bins. E.g. No more storing 65 bytes in a 128 byte
bin, but the bucket would go from array to AVL Tree, which is a decent
trade-off for all the O(1) searches during collection.
The downsides of it is that adding roots would force falling back on the
previous/slower searches, so it's either GC or no GC. Also, everything
in D would become a ' pointer rather than * (which would then be legacy)
I think everything everywhere would have to change for this to be possible.
