What's the go with the GC these days?

[H. S. Teoh]

On Sun, Jan 06, 2019 at 05:11:19AM +0000, Neia Neutuladh via Digitalmars-d wrote:
> On Sat, 05 Jan 2019 20:34:30 -0800, H. S. Teoh wrote:
[...]
> One of the reasons I know as much as I do about Unicode is that I
> ported some code from D to C# and was annoyed by the C# code taking 50
> times as long and allocating 17000 times as much memory. The main
> culprits were UTF-16 and copy-on-substring. To resolve that, I made my
> own string type.  (And used Mono's ahead-of-time compilation and did a
> couple other things.)

Yeah, Walter's right on the money about copy-on-substring being a big
performance hit in C/C++, and apparently also C# (caveat: I don't know
anything about C#).  D's slices really does eliminate a lot of the
background cost that most people don't normally think about.


> >> (You'd have a stop-the-world phase that happened infrequently.
> >> Casting something to shared would pin it in the thread it was
> >> allocated from.)
> > 
> > How does this solve the problem of shared, though?  The last time I
> > checked, casting to/from shared is the main showstopper for a
> > thread-local GC.
> 
> The issue with a thread-local GC and casting to shared is that the GC
> for thread A doesn't know about references held by thread B. That
> means thread A might collect and reuse that shared object.
> 
> If we had a runtime call in the cast to shared, thread A's GC can
> record that that object is possibly referenced from another thread. It
> won't collect it until a stop-the-world phase says it's not
> referenced.
> 
> This would give teeth to some of the undefined behavior we currently
> have.

Ahh, I see what you mean.  Hmm, neat idea.  Might actually work!  Worth
exploring, I think.


> > Now that I think of it, we could deal with pointers in unions the
> > same way -- if the compiler detects it, then trigger conservative
> > mode in the GC.
> 
> Right. In the past when people have looked at this problem, the idea
> was to treat anything that could possibly be a pointer as a pointer.
> 
> > With these two out of the way, a generational GC for D seems closer
> > to the realm of possibility.
> 
> I'm not sure how much sense it makes to have a generational GC without
> write barriers.

True.  But it would allow at least a precise GC.  And perhaps a few
other GC improvements that are currently not possible.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway