On Wednesday, 10 July 2013 at 14:01:51 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:
thedeemon:
No mature GCed languages behave that bad.
I think there is one JavaVM that manages to avoid part of the
problem you explain (and maybe it needs special kernel
support). I think all other JavaVMs suffer it, more or less.
Bye,
bearophile
Yes, the C4 garbage collector in the Azul JVM
http://www.azulsystems.com/products/zing/whatisit
http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp
They used to have special hardware, but now they use standard
kernels.
RedHat is also planning to have a go at it for the OpenJDK,
http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
--
Paulo
Interesting. There was some discussion of adding a 'pauseless' GC
to Go as well, here
https://groups.google.com/forum/#!topic/golang-dev/GvA0DaCI2BU
and in that discussion Gil Tene, one of the authors of Azul,
opines
"Starting with a precise and generational stop-the-world
implementation that is robust is a must, and a good launching pad
towards a concurrent compacting collector (which is what a
"pauseless" collector must be in server-scale environments). Each
of those qualities (precise, generational) slaps serious
requirements on the execution environment and on the compilers
(whether they are pre-compilers or JIT compilers doesn't matter):
precise collectors require full identification of all references
at code safepoints, and also require a robust safepoint
mechanism. Code safepoints must be frequent (usually devolve to
being at every method entry and loop back edge), and support in
non-compiler-generated code (e.g. library and runtime code
written in C/C++) usually involves some form of reference handle
support around safepoints. Generational collectors require a
write barrier (a ref-store barrier to be precise) with full
coverage for any heap reference store operations (in
compiler-generated code and in all runtime code).
It is my opinion that investing in the above capabilities early
in the process (i.e. start now!) is critical. Environments that
skip this step for too long and try to live with conservative GC
in order to avoid putting in the required work for supporting
precise collectors in the compilers and runtime and libraries
find themselves heavily invested in compiler code that would need
to be completely re-vamped to move forward. ..."
Sounds like that precise GC talk at DConf was quite timely. Let's
hope that prediction about being too heavily invested in
conservative GC dependencies isn't too true!
-- Brian
