> we have the problem that language designers are against moving the GC forward

This is incorrect. There even was a concurrent collector written for D, but it failed for technical reasons, not anyone blocking it.

The idea that I would block any improved GC implementation for D is just silly. D is free and open source and Boost licensed. I couldn't possibly stop anyone from doing a better one.

You're free to prove me wrong about what can be done, I would welcome your implementation!

Plenty of languages have already proven D wrong, as mentioned on my language list, my contribution isn't required.

C# already offers what I care about in managed languages with C and C++ like capabilities.

And honestly why would anyone go through the trouble to prove you wrong, if in the end it eventually has the same fate as the concurrent one, that only works in Linux anyway.

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.

Which concurrent collector is this?

The one Rainer Schuetze worked on.

The one that's in druntime at the moment? Or a real concurrent GC, there are currently two different parallel GC's in druntime as I write this i.e. a forking one and a parallel marking one one which is enabled by default.

I know of a third GC implementation, by Rainer. Which is concurrent on Windows via snapshotting (but not in druntime).

http://rainers.github.io/visuald/druntime/concurrentgc.html