deps: V8: cherry-pick 597f885 #29367
Conversation
Original commit message:
[coverage] Deterministically sort collected shared function infos
Prior to this CL, collected shared function infos with identical
source ranges were sorted non-deterministically during coverage
collection. This lead to non-deterministically incorrectly-reported
coverage due to an optimization which depended on the sort order later
on.
With this CL, we now sort shared function infos by the source range
*and* call count.
Bug: v8:6000,v8:9212
Change-Id: If8bf900727591e71dbd0df621e472a4303f3a353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771776
Reviewed-by: Yang Guo <[email protected]>
Commit-Queue: Jakob Gruber <[email protected]>
Cr-Commit-Position: refs/heads/master@{#63411}
Refs: v8/v8@597f885
bcoe
added
v8 engine
nodejs-github-bot
added
the
build
| } | ||
| std::sort(sorted.begin(), sorted.end(), CompareSharedFunctionInfo); | ||
| std::sort(sorted.begin(), sorted.end()); |
There was a problem hiding this comment.
Is perhaps part of the problem that this should be std::stable_sort(sorted.begin(), sorted.end());?
There was a problem hiding this comment.
I think there's a chance that the sorting behavior wouldn't flip/flop if we used stable_sort. But I'm not sure that we know if the "counted" function element is always added first, I like that we're more explicit and bring functions with coverage to the top of the sorting order.
There was a problem hiding this comment.
Unfortunately stable_sort wouldn't help. The order of shared function infos on the heap is nondeterministic and likewise the initial (unsorted) order in sorted. A stable sort would just preserve that initial order for "same" elements.
The fix in this change is to also consider the SFI's call count while sorting. As described in the comment, it's somewhat of a hack, but works. The cleaner solution, potentially in the future, would be to remove the optimization to omit "irrelevant" coverage.
Original commit message:
[coverage] Deterministically sort collected shared function infos
Prior to this CL, collected shared function infos with identical
source ranges were sorted non-deterministically during coverage
collection. This lead to non-deterministically incorrectly-reported
coverage due to an optimization which depended on the sort order later
on.
With this CL, we now sort shared function infos by the source range
*and* call count.
Bug: v8:6000,v8:9212
Change-Id: If8bf900727591e71dbd0df621e472a4303f3a353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771776
Reviewed-by: Yang Guo <[email protected]>
Commit-Queue: Jakob Gruber <[email protected]>
Cr-Commit-Position: refs/heads/master@{#63411}
Refs: v8/v8@597f885
PR-URL: #29367
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
|
Landed in 8f33053 |
|
Note that we're supposed to get explicit 👍 for fast-tracking. (In other words, someone approving the PR is not assumed to also be approving fast-tracking. They have to make it explicit.) Not a big deal here, I don't think, but perhaps a sign that we could use a smaller/simpler set of rules and/or more-automated enforcement. (Right now, I think |
|
Also: 🎉!!! I'm excited to see how this impacts coverage reports here and elsewhere. |
|
@Trott I assumed we were good to go, because I'd added the Might be nice to add some GitHub automation around the label. |
|
but apologies, it is clear from the documentation that I should have also added a comment for folks to upvote. |
Yeah, that assumption is a reasonable one and we should probably consider either changing the rule to accommodate that assumption or else finding a way to have |
Original commit message:
[coverage] Deterministically sort collected shared function infos
Prior to this CL, collected shared function infos with identical
source ranges were sorted non-deterministically during coverage
collection. This lead to non-deterministically incorrectly-reported
coverage due to an optimization which depended on the sort order later
on.
With this CL, we now sort shared function infos by the source range
*and* call count.
Bug: v8:6000,v8:9212
Change-Id: If8bf900727591e71dbd0df621e472a4303f3a353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771776
Reviewed-by: Yang Guo <[email protected]>
Commit-Queue: Jakob Gruber <[email protected]>
Cr-Commit-Position: refs/heads/master@{#63411}
Refs: v8/v8@597f885
PR-URL: #29367
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Original commit message:
[coverage] Deterministically sort collected shared function infos
Prior to this CL, collected shared function infos with identical
source ranges were sorted non-deterministically during coverage
collection. This lead to non-deterministically incorrectly-reported
coverage due to an optimization which depended on the sort order later
on.
With this CL, we now sort shared function infos by the source range
*and* call count.
Bug: v8:6000,v8:9212
Change-Id: If8bf900727591e71dbd0df621e472a4303f3a353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771776
Reviewed-by: Yang Guo <[email protected]>
Commit-Queue: Jakob Gruber <[email protected]>
Cr-Commit-Position: refs/heads/master@{#63411}
Refs: v8/v8@597f885
PR-URL: #29367
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
This backports @schuay's fix in V8 that addresses missing function coverage.
The Bug
This bug only occurred on certain OSes, and manifested itself as follows:
Nfunctions in your script file, functions with coverage information are listed first.Nfunctions in a script file, sorting swaps and, due to an optimization, all block coverage is dropped for a function (because we see that the function itself has no coverage).The Fix
We now sort functions before applying the optimization of dropping block coverage.
This is difficult to write tests for, because it appears to be architecture dependent but @shuay has been able to confirm the patch (@shuay I don't suppose I could also get you to test against this branch).
see: #27566