Shenandoah is aimed at large JVMs (the page that link points to says 20GB or bigger), so I wouldn't just go trying it without understanding what its strengths and weaknesses are.
GCEasy looks interesting, but I'm curious how they make it free and whether there are catches. Are you associated with the company? Can you share more about your experience with G1? In particular, was the slow behavior during incremental Old Gen collections, or during an actual full GC? Theoretically, G1 is supposed to avoid full GCs by doing incremental Old Gen GCs; are you saying that you weren't able to get it to do that? Tim On May 19, 2017 8:41 AM, "nigro_franz" <nigro....@gmail.com> wrote: Hi!!! In the last period I'm enjoying using this: http://gceasy.io/ <http://gceasy.io/> You need to pass the following JVM arguments: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[file-path] With [file-path] as the location where garbage collection log should be saved. Then run your tests and upload the log to http://gceasy.io/: you'll have tons of graphs useful to get insights on the problem. About G1: on Artemis we found that with a too big old generations G1 wasn't fast enough on Full GCs (are single threaded on it!) while using -XX:+UseParallelOldGC yes, so it worth to try it. While If you have a Fedora machine wiht OpenJDK 8 or something similar, you have the option to use -XX:+UseShenandoahGC and find out if the problem is really a GC related one (do not use it in production yet!). http://openjdk.java.net/jeps/189 If ShenandoahGC will solve the issue then it is very likely to be GC problem :) -- View this message in context: http://activemq.2283324.n4. nabble.com/ActiveMQ-broker-becomes-unresponsive-after- sometime-tp4725278p4726398.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
