GCs are complicated beasts: .NET Core, 35000 lines

[Muahmmad Adel via Digitalmars-d]

On a previous reddit thread, Andrei Alexandrescu said that he 
will be rewriting the GC based on the core allocator. However 
there were no more details about this anticipated garbage 
collector features.

So will the garbage collector be a generational one? will it 
allow some sort of control over latency of garbage collection ( 
allowing a low latency option or something similar).

We had this case that we faced with ElasticSearch, where garbage 
collection firing non-deterministically (non deterministic firing 
time and non deterministic garbage collection time) causes one 
node to suddenly be not responding, increasing load over other 
nodes, which in turn when having higher load go into garbage 
collection halt one after the other, which causes the whole 
system to be unresponsive for a good amount of time.

This is an  example of thundering herd anti pattern where one 
event causes all nodes to go busy.

I am not a java developer but I think that java's GC allows more 
control over things and ElasticSearch simply didn't use these 
controls or used them inefficiently.

However, with the increasing trend towards distributed server 
applications, having more control over the garbage collector's 
performance parameters would be crucial for pushing D to this 
area.