Benchmarks use harness_begin to start collecting statistics. It is a good practice for benchmarks to trigger a GC before starting collecting statistics because that will reduce the variance caused by the state of the heap (including the amount of free space available), which will in turn influence the behaviour of subsequent GCs (such as whether they will be nursery GCs or full-heap GCs). Currently, harness_begin triggers a forced and exhaustive GC before starting collecting stats.
However, when using the benchmark (e.g. the DaCapo benchmark suite) on other GCs (such as G1 in OpenJDK), their GC and statistics framework may not have the same behaviour of triggering GC when starting collecting stats. That makes the comparison unfair if the benchmark relies on harness_begin to trigger GC.
The desired behaviour is, harness_begin shall not trigger GC, but the benchmark shall trigger GC manually before calling harness_begin.
Benchmarks use
harness_begin
to start collecting statistics. It is a good practice for benchmarks to trigger a GC before starting collecting statistics because that will reduce the variance caused by the state of the heap (including the amount of free space available), which will in turn influence the behaviour of subsequent GCs (such as whether they will be nursery GCs or full-heap GCs). Currently,harness_begin
triggers a forced and exhaustive GC before starting collecting stats.However, when using the benchmark (e.g. the DaCapo benchmark suite) on other GCs (such as G1 in OpenJDK), their GC and statistics framework may not have the same behaviour of triggering GC when starting collecting stats. That makes the comparison unfair if the benchmark relies on
harness_begin
to trigger GC.The desired behaviour is,
harness_begin
shall not trigger GC, but the benchmark shall trigger GC manually before callingharness_begin
.