We didn't adopt the concurrent one because nobody could figure out how to make it work on platforms other than Linux. Everybody wanted it.
I'm curious why you don't use Managed C++ (the one with separate GC pointers)?
I'm curious why you don't use Managed C++ (the one with separate GC pointers)?
Managed C++ was replaced by C++/CLI in .NET 2.0.
It is the best way to write bindings to native libraries on the .NET ecosystem without having to bother with getting P/Invoke or COM bindings attributes quite right.
However it is constrained to Windows, so for portable .NET code, P/Invoke it is.
In fact C# actually has three models of pointers, regular references, JIT intrisics like IntPtr/UIntPtr and raw unsafe pointers.
p.s. those seem to be persistent object focused. Persistence in a caching memory model would be a side-effect (and doesn't even have to be used). Do you know if there exists research primarily focused on 'a caching memory model' as an alternative to (general) GC or reference counting strategies?
The general idea is pretty straight forward, you have a ~fixed size chunk of (virtual) memory that active memory objects reside in. Garbage and very rarely used references get flushed to disk. Presumably, if the operating memory requirements (i.e. active objects) are met by available Ln cache layer, this should be a viable alternative to 'collecting garbage'. We're trading the overhead of tracing/ref-counting with the cost of cache mechanism. If cache is tiered, then the 'garbage' & 'rarely used' objects will end up in nice VM blocks that OS will flush to disk. One approach basically requires the use of one annotation at language level to distinguish 'long lived' objects.