On Tuesday, 10 April 2018 at 07:22:14 UTC, David Bennett wrote:
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.
Well you might want to build something as thread-local and then
publish as shared.
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?
I think it could be __to_shared(ptr, length) to let GC know that
block should be added to global set of sorts. That will foobar
the GC design quite a bit but to have per thread GCs I’d take
that risk.
But then keeping in mind transitive nature of shared.... Maybe
not ;)
Maybe it should work the other way around - keep all in global
pool, and have per-thread ref-sets of some form. Tricky anyway.
