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 do, and it isn't called Managed C++, rather C++/CLI.

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.

Its use seems to be constrained to when one needs such a bridge. Not really a ringing endorsement.

Because C# covers all bases, specially since they started bringing Midori features into C# 7 onwards, as I mentioned, I only use it for non portable code out of convenience.

In fact C# actually has three models of pointers, regular references, JIT intrisics like IntPtr/UIntPtr and raw unsafe pointers.

(~gc side-track Walter) Has anyone ever tried using a caching model for application memory? LRU evict memory objects to disk w/ a pseudo persistent memory application behavior?

Your keyword here is 'transparent persistence' (or 'orthogonal persistence'). There was quite a lot of work on this a few decades ago - https://dblp.org/db/conf/pos/index.html

Thanks for the refs.

Oh, I see. I am not aware of any work in that domain. Caching tends to be rather application-specific; despite all that phk says about varnish, mmap is not really a good general solution to the problem. Something language-specific with some awareness of the object model and perhaps access patterns could be an improvement, but not, I think, more than an incremental improvement.

It's an idea that its been attempting to get me seriously interested /g for a while now. I didn't wish to assert novelty (but to date haven't found anything).

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.

Something like "Address/memory management for a gigantic LISP environment or, GC considered harmful" <https://dl.acm.org/doi/10.1145/1317203.1317206>? I think that uses usual LRU mechanisms to determine what to page though.