Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

harness_begin shouldn't trigger GC #1140

Open
wks opened this issue May 24, 2024 · 1 comment · May be fixed by #1141
Open

harness_begin shouldn't trigger GC #1140

wks opened this issue May 24, 2024 · 1 comment · May be fixed by #1141

Comments

@wks
Copy link
Collaborator

wks commented May 24, 2024

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
Copy link
Collaborator Author

wks commented May 24, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant