Option -gc true considered harmful

[Jens Wilke]

On Dienstag, 2. Mai 2017 16:49:32 ICT Aleksey Shipilev wrote:
> > 30.998: [GC (System.gc()) [PSYoungGen: 144096K->3840K(153088K)] ....
> > 31.004: [Full GC (System.gc()) [PSYoungGen: 3840K->0K(153088K)]....
> > 
> > So probably the benchmark iteration starts while the full GC is in
> > progress. NB: G1 only generates one event for a forced garbage
> > collection.
> 
> Oh. Notice that in the log above, two events are just 6 milliseconds apart.

Ooops. That was an example for the events only. I didn't pick a "correct" 
sample from the middle of the runs, which may cause the trouble. 

> We might just wait a little before continuing then, like this:
>  http://cr.openjdk.java.net/~shade/jmh/gc-wait-settle.patch

Not convinced. I would say for CMS you need to wait for at least two counter 
increments and for G1 only for one. Which makes the counter a fragile 
interface for that purpose.

I saw some hacks around using a weak reference or creating an
object with finalizer code and check that the finalizer was run. I doubt that is 
a correct solution and guarantees that the full GC was run.
http://stackoverflow.com/questions/1481178/how-to-force-garbage-collection-in-java

What might work is to detect the correct increment first by trying to issue two 
forced GCs. Or, maybe always issue two GCs to make sure the counter increment 
came from the one we triggered and was the full GC. A reasonable interface 
would be nice. Any GC specialists here?

Anyhow, it still needs to be verified that this is really causing the different 
throughput values. Best would be to check with a patched version and increment 
of two for CMS.

Cheers,

Jens

-- 
"Everything superfluous is wrong!"

   // Jens Wilke - headissue GmbH - Germany
 \//  https://headissue.com