ship with -XX:+ExplicitGCInvokesConcurrent by default

Details

Description

It's so much easier if you can safely tell people to trigger a full GC to discover their live set (see CASSANDRA-3574), instead of explaining the behavior of CMS and what the memory usage graph looks like etc etc. Shipping with -XX:+ExplicitGCInvokesConcurrent means this is by default safe.

For people that have special needs like some kind of rolling compacting GC with disablegossip, they are special enough that they can just change the VM options.

Activity

Of course the downside is that CMS is not compacting. Given that fragmentation has been an issue I have reservations about changing this behavior from the default, expected behavior. It seems to me that if people are in the "let's see what my working set is" testing phase, a STW collection is not going to cause big problems.

Jonathan Ellis
added a comment - 06/Feb/12 04:07 Of course the downside is that CMS is not compacting. Given that fragmentation has been an issue I have reservations about changing this behavior from the default, expected behavior. It seems to me that if people are in the "let's see what my working set is" testing phase, a STW collection is not going to cause big problems.

I don't understand. If you have fragmentation problems, you're going to take full gc:s that do compaction anyway when you have a promotion failure so it's not like you're not going to get your heap compacted.

Are you saying people are expected to be in the category of people that want to pre-emptively run full compacting GC:s, yet want to do so ad-hoc without changing GC settings and scripting around it?

Peter Schuller
added a comment - 06/Feb/12 04:18 I don't understand. If you have fragmentation problems, you're going to take full gc:s that do compaction anyway when you have a promotion failure so it's not like you're not going to get your heap compacted.
Are you saying people are expected to be in the category of people that want to pre-emptively run full compacting GC:s, yet want to do so ad-hoc without changing GC settings and scripting around it?

Btw I have been in a position several times of a production cluster having some kind of issue, and wanting to know what the live set is in a situation where I don't want to trigger full gcs. It's also a way to trigger CMS earlier without having to restart a node (temporarily).

Peter Schuller
added a comment - 06/Feb/12 04:20 Btw I have been in a position several times of a production cluster having some kind of issue, and wanting to know what the live set is in a situation where I don't want to trigger full gcs. It's also a way to trigger CMS earlier without having to restart a node (temporarily).

Jonathan Ellis
added a comment - 06/Feb/12 18:50 Looks like this got ninja committed during the discussion. I'm -0, for the record: people who need this can easily add it; for the majority who don't, I'd rather preserve the default behavior.

Chris Goffinet
added a comment - 07/Feb/12 02:22 - edited I am going to revert this commit. I reviewed it, and posted a note in IRC but that looks to be missed. We had been running this in prod on 0.8 for sometime, so I felt it was safe.