Clojurians Log v2
clojure-dev
Honest question: why?
Clojure doesn't leverage any new Java features, so there's not a lot of utility to upgrade the JDK quite yet
@devn Why what? Why are we still on JDK 8 or why are we deploying Clojure 1.10.1 Beta 2?
The answer to the former is we are using some libraries that are not compatible with JDK 9+ and some of them can't be updated at the moment (we have some legacy infrastructure that won't run on JDK 9+ and there is no upgrade path -- so we're rewriting that stuff in Clojure so we can upgrade the JDK behind it).
The answer to the latter is that we try to test every alpha/beta of Clojure so we can provide the core team with early feedback.
(and we're loving the cleaned-up error reporting from clojure.main in a lot of our tool chain)
that's good to hear
There are improvements that impact clojure "passively" (ex compact strings in java 9)
@seancorfield was asking about the former, because I knew you ran on latest Clojure, and so assumed you probably were also bravely bumping JDKs to match.
@devn That would make sense, wouldn't it? I've had a couple of attempts to move from 8 to 11 but we have a few third-party libraries in play that need updating and -- because they're Java libs, not Clojure -- they have breaking changes in even their patch updates in some cases.
(Redisson, I'm glowering at you!)
At least we've torn down the main obstacle to running on JDK 11 for four of our production servers (by decom'ing our giant CFML app 🙂 ).
@alexmiller did a minimal perf repo: https://github.com/ikitommi/bench, my results & versions in the README. Uses deps.edn, and just tests how fast is (merge {:a 1} {:b 2}). Tested also with openjdk8, same results.
ok? not sure what you want me to do with that. my general experience has been that each major java version provides general performance improvements measurable at the macro level on real loads. you might see something different in microbenchmarks.
ok, I guess it's the new G1 GC, which is on by default in Java11, no regression on the Clojure side (my initial worry). Good read here on the impact in perf: http://blog.mgm-tp.com/2018/01/g1-mature-in-java9/
That might be true but that's a wild guess and those are especially dangerous when it comes to performance. Given how difficult is to write reliable micro-benchmark I'd second Alex's advice to test on real loads.
@jumar rerun the java8 tests with G1 enabled, it’s 30% slower than with Java11. As the article describes, G1 is a slower GC, but works better on multicore (default criterium tests use just 1 core). G1 has gotten much faster on Java11, still bit slower on 1 core than the Java8 default one, but faster on multicore. So, the “perf regression” is a Java-thing, not Clojure. The GC defaults have just changed.
G1 is a different garbage collector with different tradeoffs than Parallel collector. Do you optimize for throughput / allocation rates? Btw. criterium is definitely a nice library but given JVM complexity it's still far from perfect. - still may lead to misleading results. This is a good post if you're interested in some perspective on intricacies of microbenchmarking: https://mechanical-sympathy.blogspot.com/2011/11/biased-locking-osr-and-benchmarking-fun.html I'm not saying you're not right just that you should be very careful what conclusions you drive from your benchmarks
@ikitommi FWIW we've used the G1 collector in production on JDK 8 for ages.
G1 @ JVM8 is a datomic recommendation