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

[Dmitry Olshansky]

On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
> On Tuesday, 10 April 2018 at 05:26:28 UTC, Dmitry Olshansky 
> wrote:
>> On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
>>> Last I remembered, you were working on a GC prototype for D?
>>
>> Still there, but my spare time is super limited lately, the 
>> other project preempted that for the moment.
>>
>>> Any news on that, or have you basically given it up?
>>
>> Might try to hack to the finish line in one good night, it was 
>> pretty close to complete. Debugging would be fun though ;)
>
> I was thinking about messing with the GC in my free time just 
> yesterday... how hard would it be:
>
> Add a BlkAttr.THREAD_LOCAL, and set it from the runtime if the 
> type or it's members are not shared or __gshared.
>
> Then we could store BlkAttr.THREAD_LOCAL memory in different 
> pages (per thread) without having to setting a mutex. (if we 
> need to get new page from the global pool we set a mutex for 
> that)

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.

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.

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.

> 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.