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:


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.

Reply via email to