What's the go with the GC these days?

[Steven Schveighoffer]

On 1/7/19 1:59 PM, Neia Neutuladh wrote:
> 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.

Yes, well said. It's more precise, and a fully precise GC is not 
possible due to how D works.

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

The pointer maps are static, and so they are stored with typeinfo I 
believe. We already store a typeinfo pointer for everything but 
low-level allocations and basic types (for destruction).

There may be tweakable cases where it's OK to be imprecise to achieve 
better speed, or have a "small pointer map optimization".

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

This is doable. Casting to/from shared should be a rare thing, and 
probably fine to hook.

However, the problem is more (for me) that the memory would have to be 
copied, as the memory is currently in one pool and has to be moved to 
another pool.

It's better probably to just allocate it shared to begin with, or copy 
it if you need to "cast" to/from shared.

Some notion of tail-modified type constructors would be really useful here.

-Steve