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 Overtone lib for instance have been the default for quite some time (ParNew GC, TLAB). Where restricting New Gen might be a good idea to reduce new gen GC latency, it can cause unwanted promotions, longer tenured GC's and in the end heap fragmentation resulting in a full defrag gc that can take 10s of seconds. Defaults are there for a reason, to take care of most situations. Any settings other than the three default Garbage Collectors (Default for shortest time to finish, CMS for shortest pause , G1 for short pauses but long running times) and at most a pause hint for their heuristics means you're entering case-specific territory and should be treating it so. This means realistic benchmarking, profiling and comparisons between different settings. I'd treat any JVM product or library with more than 2 GC parameters with care, because if they need so much tweaking as their default, you can be sure to need both a good understanding of their inner workings and JVM memory managent as well to keep them performing in your specific case. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
