[API Proposal]:Inject to GC

[Mr0N]

Background and motivation

I suggest adding the ability to inject your own class into the "Garbage Collector" by adding a Monitor property so that you can control and mark which objects are garbage and which are not. The GC collector checks objects to see if they are garbage or not, and I propose that the final check for it should be a method call from the IClear interface, which would return a value indicating whether the object is garbage or not. If the method TryCheckIsGarbage returns true, the GC collector marks the object as garbage and deletes it; if it returns false, it does not mark the object in any way.

API Proposal

using System;

GC.Monitor = new ExampleClearGarbage();


public static class GC
{
    public static IClear Monitor { get; set; }
}

public interface IClear
{

    public bool TryCheckIsGarbage(object obj);
}

class ExampleClearGarbage : IClear
{
   
    public bool TryCheckIsGarbage(object obj)
    {
        if (!(obj is RandomType randomInfo))
        {
            return true;
           
        }
        return randomInfo.text == "12345";
    }
}
record RandomType(string text);

API Usage

Alternative Designs

No response

Risks

No response

[dotnet-policy-service[bot]]

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

[huoyaoyuan]

that you can control and mark which objects are garbage and which are not.

This is achieved by using GCHandle.

I propose that the final check for it should be a method call from the IClear interface

This will destroy the performance of GC in order of magnitudes.

Moreover, GC works by marking alive object, not dead object. Only finalizable will be handled when dead, which is a tiny portion of objects. Any attempt that checks every object will certainly remove performance.

[Mr0N]

Moreover, GC works by marking alive object, not dead object. Only finalizable will be handled when dead, which is a tiny portion of objects. Any attempt that checks every object will certainly remove performance.

Calling a single method that could reduce the speed like that? At the stage of checking whether the object is alive or not

[cshung]

@Mr0N, what are you trying to achieve?

[colejohnson66]

Moreover, GC works by marking alive object, not dead object. Only finalizable will be handled when dead, which is a tiny portion of objects. Any attempt that checks every object will certainly remove performance.

Calling a single method that could reduce the speed like that? At the stage of checking whether the object is alive or not

Yes. Because checking if an object is alive is done by tracing which objects reference other objects. This is extremely fast because you just follow the pointers. Calling a method is much slower.

What are you trying to do where this would be beneficial to you?

[DrkWzrd]

"I want precise hand-crafted memory management without the burden of beign responsible of it, or learning how it is done in the deep".

The eternal Sisyphus stone of .Net.

Trying to reinvent the wheel when handles (GCHandle) exists doesn't sound good. At first, using interfaces for something that requires high performance (very high performance) is, generally speaking, a no-no. At last, allowing the GC to "run" user code so easily is a recipe for not only performance penalties, but application blow ups.

You have to think that the "application" "stops" or "pauses" while the GC is doing its job. Everything you put "to compute" in that methods that will be called when collecting, it will be a performance hit. For every instance of any of that types, for every garbage collection done.

[AustinWise]

A feature similar to your proposal already exists as an internal implementation detail of the CoreCLR GC: the reference-counted GC handle. I wrote a blog post about it last year:

https://www.awise.us/2024/03/31/gc-handle.html

However it has a lot of limitations and does not exist in MonoVM. So there would have to be a compelling use case to justify the work to expose it publicly.