CODEWITHSUNDEEP
garbage-collectionjprofiler
Juh_
Juh_

Reputation: 15549

How to interpret GC Activity graph in JProfiler?

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

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?

enter image description here

Upvotes: 5

Views: 3229

Answers (2)

Ingo Kegel
Ingo Kegel

Reputation: 48090

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

enter image description here

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

enter image description here

Upvotes: 5

the8472
the8472

Reputation: 43125

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.

Upvotes: 3

Related Questions