What's the go with the GC these days?

[Paulo Pinto]

On Tuesday, 8 January 2019 at 04:34:11 UTC, Jonathan M Davis 
wrote:
> On Monday, January 7, 2019 3:27:15 PM MST Neia Neutuladh via 
> Digitalmars-d wrote:
>> On Mon, 07 Jan 2019 14:53:50 -0700, Jonathan M Davis wrote:
>> > Given that sort of situation, I don't see how we can have the
>> > GC accurately track whether objects are thread-local or 
>> > shared. Casting
>> > is just too blunt an instrument and allows too much.
>>
>> This is exactly the situation I brought up in the post you're 
>> replying to. I explained what the solution is in the post you 
>> just replied to. That was in fact the entire point of that 
>> post.
>
> Well, then I clearly read over it way too quickly.
>
>> It requires a number of careful steps. It's not automatic. 
>> It's *mostly* automatic, and you can wrap the rest in a 
>> library. But it's expensive and it makes it easy to write 
>> incorrect code.
>>
>> To review:
>>
>> When you cast to shared, the thread-local GC pins the thing as 
>> shared. It also finds every bit of its memory that you can 
>> reach from that object, the same way as if it were doing a 
>> mark/sweep collection, and *that* is also pinned as shared.
>>
>> When you are modifying an object that's had shared cast away, 
>> you need to tell the GC not to run, or you need to pin 
>> objects-that-will-become-shared temporarily (for instance, by 
>> keeping local references to them).
>>
>> When you are done modifying an object that's had shared cast 
>> away, you need to cast it back to shared.
>>
>> This is not a good solution, so D isn't getting a thread-local 
>> GC that eliminates stop-the-world unless someone else comes up 
>> with a cleverer solution. On the other hand, it doesn't have a 
>> cost for casting away shared as such; casting shared(T) to 
>> const(T) is totally free.
>
> Yeah, such a solution wouldn't fly. Basically, you're talking 
> about having to have a way to tell the GC that you're moving 
> stuff between threads, and that would be so error prone that 
> it's not even funny. It's already problematic enough to get 
> code that deals with sharing data across threads right as it is.
>
> If we could solve the forking problem on Windows so that we 
> could actually have a cross-platform concurrent GC like the 
> Linux one that Sociomantic has used, then that would likely 
> give similar benefits (if not better) without having to muck 
> with the type system. I forget exactly what the stop-the-world 
> pause times were, but they were pretty low. If a thread really 
> couldn't afford to be stopped at all, it would still need to be 
> separate from the GC, just like now, but that would be true of 
> a solution that involved thread-local heaps as well.
>
> In any case, it's issues like these which definitely make it 
> much harder to drastically improve D's GC. We have much worse 
> constraints to work under than languages like Java, and we 
> don't have the same kind of manpower trying to improve the 
> situation. But at least D is set up in a way that works quite 
> well with minimizing heap allocations - especially with the 
> idioms that are typical in idiomatic D.
>
> - Jonathan M Davis

Yet, all the GC enabled languages happened to beat Swift with its 
reference counting, on the implementation of an high performance 
network userspace driver.

"Safe and Secure Drivers in High-Level Languages
How to write PCIe drivers in Rust, go, C#, Swift, Haskell, and 
OCaml"

https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages

The professor that organized the research thesis didn't even 
considered D for the project, and he had plenty to choose from.

And MIT is doing research with writing POSIX kernels in Go, 
https://github.com/mit-pdos/biscuit

Meanwhile C# now has all the nice features from project Midori 
for low level programming, and is getting all the love from game 
developers fed up with C++, including some very well known ones.

The theme that D's GC cannot be improved won't take the language 
very far.