What's the go with the GC these days?

[Neia Neutuladh]

On Sat, 05 Jan 2019 20:34:30 -0800, H. S. Teoh wrote:
> On Sat, Jan 05, 2019 at 11:12:52PM +0000, Neia Neutuladh via
> Digitalmars-d wrote:
>> On Sat, 05 Jan 2019 14:05:19 -0800, Manu wrote:
>> > I'm somewhere between a light GC user and a @nogc user, and I don't
>> > really know much about where we're at, or much about start-of-the-art
>> > GC in general.
>> 
>> I use the GC unabashedly and only try to make sure I reuse memory when
>> it's reasonably convenient. I've also looked into GC a bit.
> 
> I also use the GC freely, and only bother with GC optimization when my
> profiler shows that there's an actual problem.
> 
> As I've said numerous times before, unless you're working on extremely
> time-sensitive code like real-time applications or 3D game engines, D's
> GC usually does not cause much noticeable difference. Unless you do
> something extreme like allocate tens of millions of small strings (or
> other small objects) per second, or allocate huge objects rapidly and
> expect unreferenced memory to be quickly reused.

String allocation is one area where D makes it absurdly easy to reuse 
existing memory while other languages force you to go through hoops.

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

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

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