A number of researchers from Microsoft Research, University of Cambridge, and Princeton University have forked .NET, adding an API to the runtime to support manual memory management, and published details of their approach and performance improvements obtained in the paper Project Snowflake: Non-blocking Safe Manual Memory Management in .NET.
Project Snowflake is an attempt to introduce manual memory management in .NET, improvement considered useful for certain applications. Modern programming languages such as C#/.NET use garbage collection to relieve the programmers from the task of managing objects with known benefits regarding development productivity, program stability, memory safety and security. But garbage collection comes with a performance cost which is not perceived for most cases but can be problematic for some. Snowflake researchers cite data analytics and stream processing running on systems with hundreds of GB of heap memory as ones which can benefit from manual memory management.
Snowflake proposes introducing manual memory management in parallel with the garbage collected one, developers generally using the GC mechanisms but also being able to go manually when circumstances call for it. The changes introduced to the runtime would not affect existing applications, and would improve the performance of multithreaded applications. Snowflake enables the "allocation and deallocation of individual objects at arbitrary program locations, and we guarantee that manually managed objects enjoy full type- and temporal- safety, including in the presence of concurrent accesses."
This project introduces two main new concepts, object Owner and Shield, and it is implemented as an API at the CoreCLR and CoreFX level. The Owner is a location in the stack or heap that holds the unique reference of an object allocated in the manual heap. An Owner is obtained from a Shield which is introduced to avoid deallocation of manual objects when accessed by multiple threads. The Shield makes sure the object is removed from the heap only when the last thread using it deallocates it. The research paper explains this in more detail:
Our solution … is inspired by hazard-pointers, a technique originating in the lock-free data structure literature. We introduce a mechanism to publish in thread-local state (TLS) the intention of a thread to access a manual object through one of these owner locations. This registration can be thought of as creating a shield that protects the object against deallocation and grants permission to the thread that issued the registration to directly access the manual object e.g. call methods on it or mutate its fields. At the same time no thread (the same or another) is allowed to deallocate the object and reclaim its memory. Once client code no longer needs to access this object, it can dispose the shield, that is remove the reference to this object from its TLS. It is not safe to directly access the object that has been obtained from a shield, after the shield has been disposed because, following this disposal of the shield, the actual deallocation is allowed to proceed.
The paper includes the results of a number of tests measuring the performance benefits of using Snowflakes against GC in certain scenarios. They obtained "up to 3x savings in peak working sets and 2x improvements in runtime" which represent good savings. This is possible because for very large pools of objects the GC spends considerable time walking the object graph to free up memory.
Microsoft has not elaborated on the plans to include or not the Snowflake technology in .NET, but we can expect future versions of .NET to incorporate something like that considering its non-intrusive and safe mechanism.