[Local GC] Local GC Feature Meta-Issue

[swgillespie]

This issue tracks all of the sub-issues related to Local GC on CoreCLR.

The current status of Local GC on CoreCLR:

1. With the FEATURE_STANDALONE_GC feature define, the VM can build such that it is capable of loading and running a standalone GC.
2. With the FEATURE_STANDALONE_GC_ONLY CMake feature define, the VM builds and links directly against a standalone GC.
3. The GC currently does not link when built as a shared library, but is very close.

Here's the list of known work items for getting a standalone GC off the ground and running (required for bare-minimum functionality):

• https://github.com/dotnet/coreclr/issues/11510 - [Local GC] Undefined symbol when building standalone: IsGCThread and IsGCThreadSpecial

• https://github.com/dotnet/coreclr/issues/11511 - [Local GC] Undefined symbols when building standalone: CPUGroupInfo and NumaNodeInfo

• https://github.com/dotnet/coreclr/issues/11512 - [Local GC] Undefined symbol when building standalone: g_SystemInfo

• https://github.com/dotnet/coreclr/issues/11513 - [Local GC] Undefined symbol when building standalone: g_TrapReturningThreads

This will allow a standalone GC to link as a shared library. From there we can begin testing our basic GC scenarios.

More advanced GC functionality (and performance) work items, required for shipping this feature but not for basic functionality:

• https://github.com/dotnet/coreclr/issues/12170 - [Local GC] Handle table and the DAC

• https://github.com/dotnet/coreclr/issues/8268 - Local GC: make the rest of diagnostics work. (The DAC portion is complete for non-handle-table purposes. The rest remains to be done.)

• https://github.com/dotnet/coreclr/issues/8362 - Local GC: GCToOSInterface platform detection. Performance is going to be terrible without this.

• https://github.com/dotnet/coreclr/issues/11514 - [Local GC] Enable feature: FEATURE_EVENT_TRACE

• https://github.com/dotnet/coreclr/issues/11515 - [Local GC] Enable feature: GC_PROFILING

• https://github.com/dotnet/coreclr/issues/14701 - [Local GC] Compile without FEATURE_REDHAWK

• https://github.com/dotnet/coreclr/issues/11517 - [Local GC] Enable feature: FEATURE_APPDOMAIN_RESOURCE_MONITORING

• https://github.com/dotnet/coreclr/issues/12043 - [Local GC] Combine related threading GCToEEInterface callbacks

These issues are for CLR developer diagnostics only and are not necessary for feature correctness or performance:

• https://github.com/dotnet/coreclr/issues/11516 - [Local GC] Enable feature: STRESS_HEAP

• https://github.com/dotnet/coreclr/issues/11519 - [Local GC] Enable feature: WRITE_BARRIER_CHECK

[swgillespie]

Update:

The GC does build as a shared library now and is mostly functional, pending a few bug fixes. The remaining work is to ensure that the GC can build without FEATURE_REDHAWK and that all diagnostics retain feature parity with a non-local GC. All of this must be done without regressing the performance or correctness of non-standalone GCs.

[swgillespie]

Tracking remaining issues:

• Local GC Issue Query
• Local GC PR Query
• Local GC 2.1.0 Issue Query

cc @sergiy-k

[swgillespie]

Project is also updated: https://github.com/dotnet/coreclr/projects/3

[4creators]

@swgillespie Seems that current status of Local GC project is more advanced than this issue indicates. Could it be possible to update this issue and project docs?

[teo-tsirpanis]

@dotnet/gc all linked issues in the OP are closed. Can we close this?

[SzpejnaDawid]

@Maoni0 Hey, can I ask if using my own GC via DOTNET_GCPath is functional and is there any documentation describing how to create a custom GC? Thx for answer