mmtk / mmtk-core

Memory Management ToolKit
https://www.mmtk.io
Other
379 stars 69 forks source link

`harness_begin` shouldn't trigger GC #1140

Open wks opened 6 months ago

wks commented 6 months ago

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.

wks commented 6 months ago

But I also remember that when running benchmarks, we also disable System.gc() and completely rely on harness_begin to trigger GC. See the ignore_system_gc option and the ignoreSystemGC option in JikesRVM