Full manual garbage collection

[bigpilot]

Would it be useful to have FULL manual garbage collection in .NET where the program determines when the Garbage Collector runs and to limit the time the GC can run?

new property:

GC.Mode = GCCollectionMode.Manual or GCCollectionMode.Automatic // in addition to the methods that already exist

new method:

GC.Collect(int milliseconds) // specifies the time the GC can take to reclaim memory, only applicable if GC.Mode = Manual

This would allow time sensitive applications like games or video encoding / decoding engines to be written in a .NET language.

In addition the GC could also expose some memory pressure statistics to aid the program in determining when the garbage collection should be run.

[huoyaoyuan]

Would it be useful to have FULL manual garbage collection in .NET where the program determines when the Garbage Collector runs and to limit the time the GC can run?

NoGCRegion can provide some functionality around this. However, it needs to be used very carefully about time and allocation speed, or the process will run out of memory quickly.

GC.Collect(int milliseconds) // specifies the time the GC can take to reclaim memory, only applicable if GC.Mode = Manual

A GC consists of several phases, some of them are capable to run in a background thread. The "time" is not clearly defined here.
And also, GC doesn't work as consume some time to reclaim some memory. Instead, it marks alive objects and compact (reorganize) the heap when appropiate. Once the compact phase has started, it may not be possible to pause or cancel at all.

This would allow time sensitive applications like games or video encoding / decoding engines to be written in a .NET language.

There are such engines implemented with .NET. Reducing GC pause time is a complex topic. There are already discussions like #65850.

In addition the GC could also expose some memory pressure statistics to aid the program in determining when the garbage collection should be run.

The heuristic of GC itself would probably do much better than application.

For instance, one situation application can inform GC is that a hugh graph of objects just died.

[bigpilot]

The idea would be that the garbage collection does not run in a background thread but halts the current program execution until the allotted time for the garbage collection runs out.

[Clockwork-Muse]

... this behavior is known as "pause the world" GC, and if you're not careful it can manifest as a hung application.
The multithreadedness of the GC is normally a feature, because large chunks of the process can be run outside your main application loop. Is there a reason you want to remove that?

Note that most of the things games/video apps would be dealing with may respond better to something as simple as pooling (or structs), without requiring a whole new GC.

[huoyaoyuan]

Background GC will reduce the pause time. In current design, GC only needs to pause when it's doing something that can't be done at background. It can also choose to do background phases only and skip blocking phases.