TM: assert correctness of v8-v5

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Alex Miller, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment, 2 obsolete attachments)

433.63 KB, patch
Robert Sayre
: review+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
Created attachment 463404 [details]
v8-v5 correctness v1

This adds all of the v8 benchmark tests to trace-tests so make sure that they're executed correctly, and all of the correctness checks have been converted to use assertEq so that they'll run in the shell. (Note that it does not check the correctness of the regex tests.)
Nice. I think TM could use this too.
Summary: JM: assert correctness of v8-v5 → TM: assert correctness of v8-v5
(Reporter)

Comment 2

7 years ago
Created attachment 463406 [details] [diff] [review]
v8-v5 correctness v1

forgot to check the patch box...
Attachment #463404 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #463406 - Flags: review?(sayrer)

Updated

7 years ago
Attachment #463406 - Flags: review?(sayrer) → review+
(Reporter)

Comment 3

7 years ago
Created attachment 464666 [details] [diff] [review]
v8-v5 correctness v2

The PRNG for splay had to be truely random in order to not cause the splay tree to become a linked list, thus causing the recursion limit to be tripped when running not inside jaegermonkey.

All that was changed was copying the PRNG from base.js into check-splay.js and a typo in one of the asserts.
Attachment #463406 - Attachment is obsolete: true

Updated

7 years ago
Attachment #464666 - Flags: review+
http://hg.mozilla.org/tracemonkey/rev/f249c40b2cf8

by request
Whiteboard: fixed-in-tracemonkey

Comment 5

7 years ago
http://hg.mozilla.org/mozilla-central/rev/f249c40b2cf8
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(In reply to comment #0)
> (Note that it does
> not check the correctness of the regex tests.)

Out of curiosity, why'd we choose to avoid those?
(Reporter)

Comment 7

7 years ago
Not for any very legitimate reason... it would have been a significant amount of work to go through and find all of the expected results of the regex things that were being done, and between the testing and fuzzing that's been done on yarr, I hoped it wouldn't be needed. Just as being a part of trace tests though, we still get to know if running the test results in a crash or out-of-memory failure.

If you'd like their correctness to be asserted though, I have no problem working it.
(In reply to comment #7)
> If you'd like their correctness to be asserted though, I have no problem
> working it.

Sounds good -- these regexps are supposed to be representative of actual workloads on the web, and I don't think our regexp test suite has sufficient coverage of "average" stuff, let alone everything else. ;-)

Even more interesting would be to run these through pre-yarr, v8, and jsc to make sure they all produce the same results. Otherwise, benchmark scores don't matter much, eh?
You need to log in before you can comment on or make changes to this bug.