Measure the overheads of reading Rust timers and performance counters

[caizixian]

It seems like the JVMTI agent for OpenJDK might have 5~10% overheads to the total wall-clock time, not sure whether .stw and .other are equally affected. Would be good to check this for MMTk.

• Baseline
• Invoking hardness_begin and harness_end but don't specify any perf_events. This uses Rust's SystemTime.
• Additionally use software event TASK_CLOCK
• Use hardware events such as cycles, and cache misses.

[k-sareen]

This is MMTk commit d93262b, built with PGO (trained on fop) with a 1.5x Immix minheap. Everything is normalized to the baseline.

Just using the timers is 1% faster than baseline. This is strange and likely to do with the JIT compiler's decisions. Both the no probes (i.e. specifying DaCapo to use the Harness class with a callback but not providing the -Dprobes= option) and the software perf counters have a 0.2% overhead in comparison to the baseline. Hardware + software perf counters has a 2.5% overhead.

Obviously this is very benchmark dependent though, with avrora having the largest overheads.

[k-sareen]

These are the results for the JVMTI agent for stock GCs. I'm using the same heap sizes as above. lusearch's results are really weird...