Opt-in thread-local GC (tgc): per-thread heaps without global STW

[Ryan Johnson]

Hi all,

I've been thinking about something awkward in how D handles 
memory and threads.

In D, threads mostly keep their own data by default, and 
std.concurrency already nudges you toward message-passing instead 
of sharing everything. That feels a lot like little independent 
workers talking to each other.

But the garbage collector still acts like one big shared junk 
drawer for the whole program. When any thread needs a cleanup, 
the GC freezes every registered thread for a moment — even 
threads you carefully wrote as @nogc so they could stay smooth 
and realtime.

So I prototyped an optional collector called tgc (thread garbage 
collection). Think of it as “each thread gets its own mini heap 
and cleans up its own mess.” I might call that idea a “realtime 
GC,” but I'm using "TGC" or "tgc" in usage notes.

You turn it on like this:

   ./app --DRT-gcopt=gc:tgc

What it tries to do:
- Give each thread its own heap
- Let a thread collect garbage without pausing the other threads
- Leave the normal default GC alone unless you ask for tgc

First version is deliberately careful: prefer copying data or 
sending immutable messages between threads. If you hand a block 
of memory from one thread to another, the owning thread still 
cleans it up later. Fancy “shared regions between only some 
threads” is planned for later, not in this first cut.

Links:
- Upstream PR: #23514
- Longer explanation: 
https://dlang-supplemental.github.io/docs/docs/blog/thread-local-gc-tgc.html
- Short news note: 
https://dlang-supplemental.github.io/docs/docs/news/tgc-upstream-pr.html

Important: this is not “replace D’s default GC.” It’s an opt-in 
path for apps that care about pauses. Past forum discussions 
worried that built-in thread-local heaps get messy with `shared` 
/ `immutable`; making this pluggable and optional keeps that risk 
small.

I’d love feedback on the idea, what’s too limited in v1, and 
whether this should become a formal DIP. Comment on the PR or 
reply here.

Thanks,
Ryan / dlang-supplemental