Simon, can you triage?

Weird, the bisect didn't manage to get ANY values the first round of Gathering Reference Values, despite running the test 6 times each. Only after maxing out it's attempts did it get a couple values from either good or bad. The test didn't seemingly fail either. I kicked off another bisect, this time without a story filter.

+mythria test owner

I tried this locally and it does not generate results for v8-gc-memory-mark-compactor_max metric. This is what bisect is trying to gather I think. The benchmark generates most other metrics. I will look a bit more into it.

v8-gc-memory-mark-compactor_* metrics will be reported only when there was a memory reducing GC. So if there is no memory reducing GC, this metric will not be generated. 

Also cc'ed ulan, who knows more about this metric. 

The v8-gc-memory-mark-compactor_max metric looks for memory-reducing GC events in the trace. If there are no events it will not produce a value. I will change it to produce 0 in such cases.

+nednguyen for thoughts about this benchmark

We can't really bisect on a benchmark that only sometimes produces values.

Tim: this is another case of dynamically generating metrics causing us problems :-(
(See #7 & #8)

Simon: for a workaround, can we just assume not producing value == zero?

Even if we do report a zero here, we're likely to end up with extremely noisy output, right? If our metric is based on a specific event which only sometimes happens, it feels like we've probably already lost, regardless of how we choose to report the data.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot