On Tuesday, 10 April 2018 at 06:43:28 UTC, Dmitry Olshansky wrote:
On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
I was thinking about messing with the GC in my free time just yesterday... how hard would it be:


Lost immutable and that thread-local is often casted to immutable, sometimes by compiler.
See assumeUnique and its ilk in Phobos.

Same with shared - it’s still often the case that you allocate thread-local then cast to shared.

People cast from thread local to shared? ...okay thats no fun... :(

I can understand the other way, thats why i was leaning on the conservative side and putting more stuff in the global pools.

Lastly - thanks to 0-typesafety of delegates it’s trivial to share a single GC-backed stack with multiple threads. So what you deemed thread-local might be used in other thread, transitively so.

Oh thats a good point I didn't think of!

D is thread-local except when it’s not.

If thats possible we could also Just(TM) scan the current thread stack and mark/sweep only those pages. (without a stop the world)

That is indeed something we should at some point have. Needs cooperation from the language such as explicit functions for shared<->local conversions that run-time is aware of.

So the language could (in theory) inject a __move_to_global(ref local, ref global) when casting to shared and the GC would need to update all the references in the local pages to point to the new global address?

And when a thread ends we could give the pages to the global pool without a mark/sweep.

The idea is it works like it does currently unless something is invisible to other threads, Or am i missing something obvious? (quite likely)

Indeed there are ugly details that while would allow per thread GC in principle will in general crash and burn on most non-trivial programs.

Okay, thanks for the points they were very clear so I assume you have spent a lot more brain power on this then I have.

Reply via email to