System.gc() by default causes a full gc to be done. For G1 this means
a serial gc which could be slow.

Adding some comments here based on a conversation with Kirk Pepperdine and Charlie Hunt.

These comments kind of step back and ask a few questions which might influence the default behavior for System.gc() under G1.

One might step back and ask if the default behavior under G1 for a call to System.gc() would be to initiate a G1 concurrent cycle. In other words, this would imply making -XX:+ExplicitGCInvokesConcurrent the default for G1.

I suppose one might have reservations about G1 doing an invocation of a concurrent cycle in the case where the JVM is running short on available regions (space) and needed a more timely / urgent GC action. But, in that "not timely enough" case, G1 would likely run into a "to-space exhausted" which would fall back to a Full GC any way. Granted that Full GC initiated from a to-space exhausted is gonna be a little slower because you have to do some collection in place because there is not an available region to evacuate too.

I suppose another consideration would be that anyone who wanted a concurrent cycle initiated on System.gc() could just enable ExplicitGCInvokesConcurrent at the command line. Yet, at the same time, if one wanted the stop the world, single threaded Full GC behavior for G1, he or she could disable ExplicitGCInvokesConcurrent.

I think what should be taken under consideration is what is the most desirable "out of the box" behavior upon someone call System.gc(). Should it be a single threaded stop the world GC (a very long pause), or should it be an initiation of a G1 concurrent cycle?

There is probably a better user experience for most folks with G1 with a default of ExplicitGCInvokesConcurrent for G1.

I suppose this discussion could be expanded to looking at where in the JDK a call to System.gc() is made, and perhaps in each of those cases try to reason about what would be most desirable behavior.