Your 99th percentile latency has spikes that the application code cannot explain. How do you check whether garbage collection is responsible?

Turn on garbage collection logging and line the pause timestamps up against the slow requests. If the spikes match pauses, look at allocation rate, promotion and heap headroom before touching any flags, since most pauses come from allocating too much or a heap that is too small. If they do not match, check time to safepoint, since a long safepoint stalls every thread and looks exactly like a garbage collection pause.

I want two timelines. Unified logging gives me every pause with its cause and duration, and my traces give me the slow requests, so the first question is simply whether they line up. If they do, I resist changing flags and look at why. Usually the service allocates enormously per request, something like building intermediate lists in a loop or logging a serialized payload on every call, so the fix is allocating less. Sometimes the heap is just too tight and collections run constantly, or in G1 the code allocates large arrays that become humongous objects and behave badly. Only after that would I consider moving to a low pause collector, and I would treat it as a tradeoff rather than a free win. If the pauses do not correlate, I look elsewhere: time to safepoint can be long even when the collection itself is short, so a thread in a counted loop stalls everyone. I have also chased a case that turned out to be container CPU throttling, where the process was descheduled entirely and no JVM tuning would have helped.