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.



Reply via email to