Alternative Memory Management Strategy for .NET

[AzatTazayan]

.NET has a very polished GC and it is working quite well, but when you are working with data-intensive applications that are making a lot of allocations as result you will have a lot of GC cycles that is affecting in overall performance and memory continues to grow. Recently I found this article
Alternative Memory Management Strategy for .NET and this will be the best solution for data process and cleanup memory completely. Think having this in .NET will make .NET the most powerful platform where you will have rich API and memory control at the same time

[huoyaoyuan]

@dotnet/gc

[En3Tho]

1. Perf advices from Microsoft he citied work as well in C++ as they do in C#. Here I mean object pooling, stack allocating, using structures and keeping in mind how allocator youre using works under the hood (meaning GC in C#)

2. NRT did don't break anything, it's not a breaking change and it's not a memory feature (like what). A lot was invested in adding annotations but at the same time people are free to use it or not. It's not even a runtime feature.

3. I'm not sure why he goes against manual optimizations like object pooling and then is totally up for yet another manual thing like delete.

4. Everything has a cost. "delete friendly" heap might not be GC friendly at all. We have to account for any risk of regressions coming from introducing a split like this. Academic research data is often not what is seen in real world.

5. There are other strategies more suited for this in my opinion like escape analysis. Objects could be stack allocated or Jit could somehow see that this small graph is not escaping to actual GC heap so it can be allocated somewhere not on GC heap and deleted afterwards. All of this can be done automatically.

P.S. Allocating 1000 times and freeing a 1000 times is not a memory leak...

[Maoni0]

We thought the Snowflake research project was a very worthwhile experiment and I worked with MSR to explore this idea. The project could show gains for specific best case scenarios but unfortunately the attempt to extend that to good results across a broader set of scenarios important to our .NET developers was unsuccessful. This was not an unusual outcome. Many experiments start out promising but may not pan out. It's possible we'll return to this idea in the future and try to resolve more issues but currently we think there are other features that would bring more value.

[AzatTazayan]

.NET should allow manual memory allocation and deallocation. There are a lot of ways to do that, like having manually controllable pages or reference counting like in Swift, etc. But the main point is why we need that, as GC is very good but not perfect and it is slow (when you are working on desktop and GC decades to freezes rendering thread as well and your app is not responsive any more, enabling server mode doesn't help here). You also can have a lot of cases when GC not cleaning memory (no leak) and continue allocations and you don't have control over it. Application users who don't know about programming complaint that memory usage is very big but we just telling them wait some time and it automatically decries. Why developers shouldn't be allowed to immediately release that as they understanding what they are doing?! Sometimes developers creating multiply child processes to do some work and fully cleanup memory this is more common on desktop development but it is too complex and requires serialization and deserialization. Developers need that freedom and they are smart enough to correctly use it!

[davidfowl]

There are lots of other languages and runtimes that do this and right now .NET isn't one of them. I won't say it's niche but as @Maoni0 said it's not the direction we're going on at the moment nor are we willing to invest more time (MSR spent ALOT of time) on currently.

[En3Tho]

I would argue that .Net GC is "slow". It has certain anti-patterns you should be aware of and they are described in MemDoc as far I as remember (like Gen2 -> Gen0 references). If you have any concrete scenarios you're willing to share then please do so. Otherwise it's like ".Net should do it because someone theoretically assumed it will be good in a blog". It's way more complex than that.

Also, any perf critical or allocation heavy parts can use structures/pooling.

[Clockwork-Muse]

You also can have a lot of cases when GC not cleaning memory (no leak) and continue allocations and you don't have control over it.

Because GC doesn't run if there isn't sufficient memory pressure (because it can take resources). You can schedule a run somewhat, but it's not usually necessary.
Note that you still get some of this behavior to an extent with manual memory management in the native allocator, since just because you delete an object doesn't mean it gets released back to the OS

Developers need that freedom and they are smart enough to correctly use it!

You can - write it in C and call it as a native extension, and you can have complete control over the memory.

[Xyncgas]

either there's an absolute improvement or there isn't, because then we are in the territory of benchmarking and blackbox programming where the factor of performance is no longer the brilliance but leaving it to chances and luck and all the AI banaza

[Clockwork-Muse]

At a certain point, there are no longer performance improvements, only tradeoffs - in terms of other resources (memory vs cpu, for example), readability, platform specifics...