Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky]

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.