My understanding is that some people just restart the JVM periodically to avoid GC pauses. How does that compare for web applications?
A restart transformed a JVM with a fragmented old gen into a JVM with fresh old gen using X1 wall-clock seconds and Y1 cpu time/watts.
A full GC transforms a JVM with a fragmented old gen into a JVM with fresh old gen using X2 wall-clock seconds and Y2 cpu time/watts.
Have you ever compared X1,Y1 vs. X2,Y2?
I suppose in theory you could use JMX instrumentation and tie it to your load balancer, but I've never heard of it being done.
(It's actually quite a good idea! hmm...)
My point was that a full GC does not need to re-profile the code, re-JIT the code and warm data caches, like a newly restarted JVM does. Sending a user request to a JVM to be run in an interpreter with cold caches is not good for user satisfaction, so a newly restarted JVM needs to be given mock requests to warm it up (like a script for PGO static compilation). A JVM doing a full GC does not need all that to become fully ready, and if it has enough free RAM to defragment quickly, the process should be much more efficient.