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:
[snip]
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.
