Hacker News Reader

Comment by Semaphor | Hacker News Reader

.NET is also regularly improving their GC, aren’t they?

Not only the GC, since version 7, most of the Midori stuff has been landing on C# (and to some extent F#), turning into a kind of "Managed C++".

Contrary to the WebAssembly speech, CLR was one of the very first VMs to have support for C like languages, but those capabilities were only fully surfaced to the original Managed C++ (.NET 1.0) and C++/CLI (2.0 onwards).

So now those capabilities are being exposed into C# as well.

For example stack allocation of arrays is now also valid in safe contexts.

You can apply using to any type that has Dispose() without inheriting from IDispose.

Memory slices are now also a thing and native function pointers for example.

> apply using to any type that has Dispose() without inheriting from IDisposable

Last I saw, this was still being debated by the LDT and weighed against similar proposals such as introducing a `defer` keyword like Swift/Go.

You can use it today on C# 9.

Can you link to any documentation/examples?

Also notably Go, though really all GC languages which care about performance, of which there are quite a few.

Go isn't playing in the same league though since their GC is non-generational and non-compacting. A lot of the difficulties implementing concurrent GCs comes from moving things between generations and compacting.

I had this benchmark[0] in mind while writing the comment, though perhaps Go does well there by avoiding GC rather than having fast GC as-such? That would explain why its performance is close to the non-GC languages.

[0] https://awesomeopensource.com/project/ixy-languages/ixy-lang...

Without digging into that benchmark, Go leans on stack allocation a lot more than many GC languages, and that’s a big part of why Go is able to achieve otherwise impressive performance. The same mechanism (idiomatic value types) that allows Go to elide GC in many cases also permits better cache coherency—there are fewer pointers into random regions of the heap so cache lines need to be flushed less frequently.

Is that a good or bad thing? What’s the trade-off being made here?

Compacting GC tends to have cheaper allocs and longer pauses (allocs need to be moved to different regions of memory and pointers to those allocs need to be rewritten to point to the new memory regions) while noncompacting has the opposite: slow allocations and small pause times.

Though many part of compaction can be moved to a parallel thread, can’t it? The actual stop-the-world time can be quite small that way (using read-barriers though)

I’m not so sure about barriers, but compacting requires rewriting pointers that are shared with the mutator threads, so it seems hard to parallelize.

As far as I know, this is the “secret” of ZGC at least, it replaces the usual write barriers with read ones. So a parallel thread is free to move an object to a new place, and any thread trying to access it will at that point lock said object. This will have a performance impact (the usual write barriers have better throughput because they only “lock” when writing an object), but more of the GC can be parallelized.

But I’m by no means anywhere close to an expert in the topic.

Interesting. What about an application thread (“mutator” in GC parlance) that tries to write to the pointer? Does that hit the read barrier as well? Does this imply worse application throughout to improve GC metrics? If so, I wonder how much worse? (Not asking you per se, but wondering aloud)

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

That article is beyond out of date when it comes to Java GC.

The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.

Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.

Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.

It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.

Yes, although I'd say that .NET is still a little tied up with how fractured their environment is. There is a lot of tech debt sunk into the .Net Framework, and it'll be awhile before it really gets flushed away.

> There is a lot of tech debt sunk into the .Net Framework

I’m working on a website that has been growing since 1996… The chances of us ever migrating to .NET 5 and onwards is basically zero.

Reply on news.ycombinator.com