On Friday, 6 February 2015 at 09:38:48 UTC, Muahmmad Adel wrote:
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.
Each JVM (Oracle, IBM, HP-UX, ...) has a different set of knobs
to turn.
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABFAFAE
And visual monitoring tools to go alongside them. In Oracle's case
http://visualvm.java.net/
http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
However it is true that in such types of applications, there are
still a few issues to tackle in Java, which D already handles
without problems like real generics, value types, painless
integration with C and C++ code.
All issues to be fixed latest by Java 10 time-frame (Projects
Panama, Valhalla and Sumatra).
--
Paulo
