Use of CoreCLR GC in conservative stack scanning mode

[joshpeterson]

In the (currently internal) Unity prototypes using CoreCLR as an embedded JIT runtime, we have been using the CoreCLR GC in its conservative stack scanning mode. We understand this mode is not supported for production use. Is this something Microsoft would consider supporting?

It looks like existing Unity native code does enough access to managed objects that we will need to run in this mode to use the CoreCLR GC. We can work on limiting this kind of access in the Unity code, but that is a task that will take much longer than our planned CoreCLR migration. So we would like to use conservative stack scanning now.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[joshpeterson]

It looks like area-GC-coreclr would be a good label for this.

[joshpeterson]

cc @jkotas @Maoni0

[jkotas]

The conservative stack scanning mode has functionality and performance issues.

• It is not unusual to see code out there that depends on the precise scanning and unreachable objects to get released in finite amount of time. The conservative stack scanning breaks it intermittently.
• It adds about 20% GC overhead due to additional roots and pinning in GC intensive workloads on average. You can get easily get outliers when a bad pointer gets stuck on the stack.

Is this something Microsoft would consider supporting?

I see conservative stack scanning mode as community supported. We are fine with taking fixes for it, assuming these fixes would not conflict with the precise stack scanning mode.

We would not be able to make it officially Microsoft supported or recommended to use in CoreCLR runtime. Microsoft supported means that the feature has to be handle workloads like https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-is-on-net-6-0/ with confidence. The conservative stack scanning is too brittle to do that.

[ghost]

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

Issue Details

---

In the (currently internal) Unity prototypes using CoreCLR as an embedded JIT runtime, we have been using the CoreCLR GC in its conservative stack scanning mode. We understand this mode is not supported for production use. Is this something Microsoft would consider supporting?

It looks like existing Unity native code does enough access to managed objects that we will need to run in this mode to use the CoreCLR GC. We can work on limiting this kind of access in the Unity code, but that is a task that will take much longer than our planned CoreCLR migration. So we would like to use conservative stack scanning now.

Author:	joshpeterson
Assignees:	-
Labels:	area-GC-coreclr, untriaged
Milestone:	-

[joshpeterson]

I see conservative stack scanning mode as community supported. We are fine with taking fixes for it, assuming these fixes would not conflict with the precise stack scanning mode.

What level does community support have with respect to testing? We're fine to maintain this where necessary, but will existing CI run with this mode enabled? Or will we need to handle that?

[jkotas]

We are fine with having cheap basic coverage in the CI runs for the community supported targets or features. For example, it would be fine to add a test under src\tests that runs with gcConservative mode and verifies that the conservative mode is not completely broken e.g. by creating a few threads, throwing some exceptions, triggering a couple of GCs. We can use this issue to track adding the test like that.

Adding the full CI coverage for the gcConservative mode would be too expensive for us. In the limit, it would almost double the CI matrix, and more than double the intermittent failures that we spend a lot of time dealing with already.

It would be up to you to ensure the quality bar you need for the gcConservative mode.

[EgorBo]

2 cents: our libs tests already aware of "conservative" mode so around a hundred of tests are disabled for it via IsPreciseGcSupported property, see https://github.com/dotnet/runtime/search?q=IsPreciseGcSupported

because of Mono obviously.

[joshpeterson]

An update from the Unity side: We've decided not to pursue this option. Instead Unity plans to adjust our code so that it will work with the CoreCLR GC in its normal operation.