How to interpret GC Activity graph in JProfiler?

Question

Lately I've been working on optimizing some code (in compute time and max memory required). To know if there is potential gain to optimize memory cost, I use JProfiler. Typically

• if it's high, I should try to reduce it globally
• if it's spiky, I should try to reduce intermediate object creation

Now, I am in the second situation, and the GC Activity graph shows spikes but that are all less than 2% (see image below). How should I understand that ?

By default, my understanding is that the sum/integrale of the GC Activity curve is an estimate of the total percent of cpu used to collect data. So here that would mean much less than the max 2%

It that correct? Am I missing something?

Answer 1

By default, my understanding is that the sum/integrale of the GC Activity curve is an estimate of the total percent of cpu used to collect data. So here that would mean much less than the max 2%

Is that correct?

Yes, that's correct. If you want to find out where the temporary objects are allocated, go to Live Memory->Allocation Call Tree and choose "Garbage collected objects" as the liveness mode

To see the classed in any allocation spot or allocation hot spot, use the "Show classes" call tree analysis.

Answer 2

By default, my understanding is that the sum/integrale of the GC Activity curve is an estimate of the total percent of cpu used to collect data.

It should be, yes.

So here that would mean much less than the max 2%

max is deceptive here. If you make your sampling interval small enough the maximum will be 100% of a time slice spent on GCing. That is when that slice is smaller than a GC pause duration. So those peaks are already averages over some larger time slices.

How should I understand that ?

That your application probably isn't spending much time on GC. But your graph only covers a relatively small amount of time, so it might not reflect major collections or concurrent cycles. Interpreting the JVM's GC logs will provide more details if you care about latency and not just throughput.