What's the go with the GC these days?

[Neia Neutuladh]

On Mon, 07 Jan 2019 10:21:58 -0500, Steven Schveighoffer wrote:
> On 1/5/19 6:12 PM, Neia Neutuladh wrote:
>> On Sat, 05 Jan 2019 14:05:19 -0800, Manu wrote:
>>> Is progress possible, or is the hard reality that the language is just
>>> designed such to be resistant to a quality GC, while the ecosystem
>>> sadly tends to rely on it?
>> 
>> Three things about D make it harder to make a good GC for it:
>> * unaligned pointers
> 
> Unaligned pointers are not scanned, and so this is not a problem. As far
> as the GC is concerned, they aren't pointers.

In that case, it's already solved! And in pretty much the same way as 
malloc'd memory.

(I was going to check but was overcome with a bout of laziness.)

>> * unions
> 
> Unions and void * (or essentially untyped blocks) are the biggest
> problems. But depending on what we want to implement, we may have
> solutions for that.
> 
> It's difficult to paint with broad brushes here. There are certain
> problems that prevent certain solutions. But, for instance, a precise GC
> is getting traction as we speak:
> https://github.com/dlang/druntime/pull/2418

That's a more precise GC instead of a fully precise GC. Unions and void[] 
mean you can't have a fully precise GC.

> But precise GC is not necessarily better performing. And it's still
> "stop-the-world".

Right. Precise means you collect more data more often, and it means you 
use up cache lines for pointer maps. It might also fragment your heap more 
(each allocation needs a pointer map, or maybe you have different pools 
for sufficiently common things like all pointers or no pointers).

> I think the biggest improvement for D's GC could be the thread-local
> pools (and avoid stop-the-world for those), but since casting shared and
> local data around is valid, I don't know how it can be implemented
> without language changes.

Like I said before, casting to shared would have to invoke a runtime 
function. That's a runtime change and compiler change, but I don't think 
the spec says anything about whether any cast might invoke a runtime 
function.