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

David Bennett davidbennett at bravevision.com
Tue Apr 10 07:22:14 UTC 2018


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.


More information about the Digitalmars-d mailing list