I should mention here that if you are tuning the GC anywhere except at the
end of your development cycle you're probably doing it wrong. 99% of the
time you'll get better performance by reviewing your algorithms, running a
CPU profiler, generating less garbage (via transients or something like
I've found Censum by jClarity to be an excellent tool to tune JVM GC
parameters to your specific application running on a particular server. You
add a few GC parameters to enable logging that the tool needs, run your app
under load for enough time to get sufficient data, and then feed the log
GC parameters used by a lot of projects are handed down like traditions for
years, even spreading to others. They're almost never re-evaluated, which means
they might actually lose out on new performance improvements, or worse, might
even cause performance regressions.
Most parameters in the
It depends. CMS or G1 would be better in common cases as you said, clojure
runtime has many short-lived objects. We are using G1 in your production.
But sometimes you would prefer system throughput rather than GC pause time,
you may try Parallel GC.
2016-04-29 19:02 GMT+08:00 Camilo Roca
Following this thread:
http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world
I was wondering if anybody has some experience regarding GC optimizations
that would work better for Clojure than the default: stop-the-world
approach.
My point being that given
