Hi Tim! Answers inlined
Tim Bain wrote > 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. Partially disagree, that link was only a fast overview of what Shenandoah is: as you rightly said, there are strengths and weaknesses beyond what a single page link could explain about a GC algorithm. A better comparison of G1 vs Shenandoah is here: https://www.infoq.com/presentations/G1-Shenandoah TLDR: 1) "mostly" G1 (region based, SATBs, uses write barriers etc etc) BUT with no remembered sets 2) no generational anymore: young won't die first!! 3) concurrent relocation using Brooks pointers (https://rkennke.wordpress.com/2013/10/23/shenandoah-gc-brooks-pointers/) -> more memory overhead and lower throughput (eg read barriers, multiple copies) 4) won't pause while evacuate IMHO the most important point that could make it a good match to be used to run a Java broker is 2: if you've an application in which you already know that queues/messages won't die soon (from a tenuring age pov), regardless to he planned heap size (=== could be not a huge heap) it makes sense to give it a try, taking in account the memory overhead involved. The common idea that S, is will suited to manage huge heaps is just an added benefit related to not being anymore bounded by object copy/marking performances in minor GCs like G1. The reasons why I've given the advice of giving it a try is mostly dependent by the fact that I'm assuming a very "busy" (from the copy operations pov) young generation or a very big old generation: like the Parallel GC, S. performs Full GCs using multiple threads (G1 not AFAIK), hence in the worst that a Full GC has to happen I'm expecting it will be shorter than G1. Tim Bain wrote > Are you associated with the company? Not, I'm not, I've used it just to have a simple GC viewer to be used instead of the ones provided by other products. Tim Bain wrote > 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? Yes I'll do for sure :) it is just a matter to write something on this forum, but need time to make the results more than a simple collection of GC logs :) As preview: with Artemis if you have a fast rate of message arrival (with no consumers), no expiration queues and you set the broker to retain them occupying the most of your old generation without leaving enough space to let the young generations (ie the fresh arrived messages) age in peace (ie having enough contiguous free space), G1 will likely run a lot of Full GCs. In this very uncommon case (it is full of anti-pattern) a Parallel GC (or S.) is very likely to perform at least shorter Full GCs, mostly due to the uses of multiple threads while doing it. Makes sense? Regards, Francesco -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-tp4725278p4726439.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
