A separate GC idea - multiple D GCs

[H. S. Teoh]

On Fri, Jan 21, 2022 at 03:16:32PM +0000, Tejas via Digitalmars-d wrote:
> On Friday, 21 January 2022 at 14:37:04 UTC, Adam Ruppe wrote:
> > On Friday, 21 January 2022 at 13:56:09 UTC, Chris Katko wrote:
> > > So a related question: Has anyone ever thought about "thread-local
> > > garbage collection"
> > 
> > The big problem is that data isn't thread local (including TLS);
> > nothing stops one thread from pointing into another thread. So any
> > GC that depends on a barrier there is liable to look buggy.
> 
> 
> Is this intended behaviour? Or was it accidental? Is it atleast
> guaranteed that only one thread can hold a muta le reference?

Immutable data is shared across threads by default.  So any immutable
data would need to be collected by a global GC.  However, you don't
always know if some data is going to end up being immutable when you
allocate, e.g.:

	int[] createSomeData() pure {
		return [ 1, 2, 3 ];	// mutable when we allocate
	}

	void main() {
		// Implicitly convert from mutable to immutable because
		// createSomeData() is pure and the data is unique.
		immutable int[] constants = createSomeData();

		shareMyData(constants);

		// Now who should collect, per-thread GC or global GC?
		constants = null;
	}

So assume we allocate the initial array on the per-thread heap. Then it
gets implicitly cast to immutable because it was unique, and shared with
another thread. Now who should collect, the allocating thread's GC or
the GC of the thread the data was shared with?  Neither are correct: you
need a global GC.  At the very least, you need to synchronize across
individual threads' GCs, which at least partially negates the benefit of
a per-thread GC.

This is just one example of several that show why it's a hard problem in
the current language.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion