Pauseless Garbage Collector (Question)

[jogibear9988]

Is there any reason why something like the Pauseless Garbage Collector wich exists for Java from Azul never was implemented for Dotnet?

https://www.azul.com/products/components/pgc/
https://www.artima.com/articles/azuls-pauseless-garbage-collector

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there any reason why something like the Pauseless Garbage Collector wich exists for Java from Azul never was implemented for Dotnet?

https://www.azul.com/products/components/pgc/
https://www.artima.com/articles/azuls-pauseless-garbage-collector

Author:	jogibear9988
Assignees:	-
Labels:	question, area-GC-coreclr, untriaged
Milestone:	-

[AlgorithmsAreCool]

I'll add the generic response that the .NET GC supports functionality that Java's GCs do not and this can complicate or invalidate optimizations that other GCs can take advantage of.

For examples, Java's GC doesn't support interior pointers while the .NET GC does

[huoyaoyuan]

I'd like to see the GC team to write some insight about benefits and challenges/drawbacks of these options. What's theoretically possible but just complex/low priority for implementation? Which features/goals have fundamentally conflict?

[jkotas]

These types of GCs typically trade throughput for shorter pause times. For example, they often use GC read barriers that make accessing object reference fields significantly slower. If you would like to understand the problem space, read the The Garbage Collection Handbook. It has a full chapter dedicated to real-time garbage collectors.

There is nothing fundamental preventing building these types of garbage collectors for .NET. It is just a lot of work to build a production quality garbage collector. We do not see significant demand for these types of garbage collectors in .NET. Building alternative garbage collectors with very different performance tradeoffs has not been at the top of the core .NET team priority list.

I would love to see .NET community experimenting with alternative garbage collectors with very different performance tradeoffs. It is how Azul came to be - Azul's garbage collector that you have linked to is not built by the core Java team.

[MichalPetryka]

Building alternative garbage collectors with very different performance tradeoffs has not been at the top of the core .NET team priority list.

I guess that having more and more official, simultaneously supported GCs would also increase the amount of work needed to maintain and improve them all, putting even more burden on the GC team which would mean that the existing GCs would be improved slower.

[jogibear9988]

Building alternative garbage collectors with very different performance tradeoffs has not been at the top of the core .NET team priority list.

I guess that having more and more official, simultaneously supported GCs would also increase the amount of work needed to maintain and improve them all, putting even more burden on the GC team which would mean that the existing GCs would be improved slower.

Yeah, but a pauseless collector for me seams to open a whole new area where .NET could be used. Even if it may be slower, but deterministic, without pauses every now and then, for some applications this could be a huge benefit.

[jkotas]

I guess that having more and more official, simultaneously supported GCs would also increase the amount of work needed to maintain and improve them all, putting even more burden on the GC team which would mean that the existing GCs would be improved slower.

Right. If it was to follow the Azul model, it would not impact the core GC team much. I believe that the core Java GC team does not spend any cycles on the Azul GC. The Azul GC is maintained by Azul that is a company with a closed source business model.

Yeah, but a pauseless collector for me seams to open a whole new area where .NET could be used.

It comes down to numbers and opportunity costs. For example, how many new developers can pauseless GC bring to .NET? It is hard to make the numbers work.

[filipnavara]

If you would like to understand the problem space, read the The Garbage Collection Handbook.

For what's it worth, beware that buying the book as eBook from the official publisher only gives access to the book through the VitalSource service. There is no way to download the book except through the DRM encumbered software, and they managed to block my account before I was even able to read a single page (no explanation given, the service just responds with 401 error and logs me out).

If you want to get the book, get it as a physical book or through Amazon Kindle and save yourself the trouble.

[fabianoliver]

We do not see significant demand for these types of garbage collectors in .NET

I am rather surprised to hear that!

I'd love to see an experimental GC, so I'm certainly quite biased. But I'd imagine predictability of latency is a very significant concern for a number of large user bases. Game development (Unity) comes to mind of course. As do many areas in finance & algorithmic trading.
In my experience, current GC characteristics are often a dealbreaker for these users. So unlikely many of the recent improvements to C# features and the runtime, which without a doubt greatly enhance the experience for existing .NET users (not that I'm complaining! :) ), I would imagine something like pauseless GC has much higher potential to bring in new developers that so far couldn't realistically choose .NET at all.

Sorry, that's it for my sales pitch; but in short, I'd definitely love to see experimentation in this area.