Any objections to making the following changes also to 5.0 ? CASSANDRA-20296 proposes the following changes:
1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young generation's size to 50% of the heap. (We know in production this can often be raised to 66% for optimal performance.) 2. When using G1, default set `-XX:ParallelGCThreads` and `-XX:ConcGCThreads` to the number of system cpu cores. (Existing settings are honoured.) 3. The auto-generated heap size is now half the server's physical RAM, capped at 16G for CMS and 31G for G1. This simplifies, and makes more appropriate, the previous algorithm. Like before this is only used if MAX_HEAP_SIZE or -Xmx hasn't been set. 4. Increase MaxTenuringThreshold from 1 to 2. Plenty of evidence now showing it has no negatives (over values of zero or one), but can sometimes have significant benefits in keeping objects in the young generation. While values above 2 don't have any noticeable benefit. 5. Default set CASSANDRA_HEAPDUMP_DIR to $CASSANDRA_LOG_DIR, to avoid hprof filling up unexpected disk volumes. Assumption here is that the logs directory is large enough to handle these dumps, and/or operators are monitoring these directories more than other randon/unknown directories. Existing values of CASSANDRA_HEAPDUMP_DIR are honoured. As can be seen, these changes are only going to impact those users that haven't set any of these flags. And a number of the defaults are wildly bad. The only question I have is how this might impact the dev experience on local machines where the ram is already used up. (It would be a fail-fast and the dev would have to set a lower MAX_HEAP_SIZE, which I think is trivial compared to the benefits here.)
