BTW I really like the Perf stuff in Roslyn, I wrote 2 posts about it, in case your interested? Although as you worked on it, it won't be anything you don't already know ;-)
Also, theUnsafe makes me snicker
The general argument is that you are still more productive by writing 90% or 95% of you app in a managed language, in the idiomatic way. Then you use crazy tricks to tune the last 10/5%. Rather than doing the whole thing in C/C++, which will give better performance, but may not be quicker (more productive) to write.
I don't know much about D, it's interesting to find that you can opt out of GC like that.
You get some of that functionality in .NET, with the new GC mode SustainedLowLatency . But it doesn't guarantee no GC, it just tried to avoid it.
> Enables garbage collection that tries to minimize latency over an extended period. The collector tries to perform only generation 0, generation 1, and concurrent generation 2 collections. Full blocking collections may still occur if the system is under memory pressure.
Basically, if you're at the point where the GC is impacting you but if you haven't tried Roslyn-level optimizations -- do that first.
But I agree that working with the grain of the GC is usually more productive.
There's no good reason for the managed heap to be anywhere near any of the native heaps in address space, on 64-bit platforms.
And the CLR's GC should actively allocate slabs well away from any native heap (trivial to do - reserve (not commit, reserve) a big contiguous chunk of address space), simply because it relies on third party code which will itself be allocating native memory; everything from GUI code to native DB drivers and their caches, quite independent of unsafe code doing manual allocation.
In the absence of a GC-aware virtual memory manager, GC-immovable memory has little relevance to paging.
(Of course, GC.Add/RemoveMemoryPressure should be called if you're doing native allocation from .net.)
If what Azul has worked on conventional Client/Server-JVMs, Sun/Oracle/IBM would've adopted it long ago.
The sad reality is that spending 99% of your time in GC, but never in a pause longer than "x units of time" qualifies as "pauseless" and if you want more throughput, you have to scale up the system so that the remaining 1% of througput is sufficiently large for your workload.
I guess this works in the markets where Azul is active (things like finance) but is useless in more conventional use cases.
Recent advances in Intel CPUs have allowed them to run on commodity hardware, but last I looked, it still required a custom kernel module.