bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Ion tests timeout on TypedObject-TypeDescrIsArrayType tests

RESOLVED FIXED in Firefox 44

Status

()

Core
JavaScript Engine: JIT
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: lth, Assigned: lth)

Tracking

unspecified
mozilla44
ARM
Linux
Points:
---

Firefox Tracking Flags

(firefox44 fixed)

Details

Attachments

(1 attachment)

Hardware: NVIDIA Jetson TK1 (Quad Cortex-A15 @ 2.3GHz, 2GB RAM).
OS: Ubuntu 14.04
Build: SpiderMonkey debug build
Command line: ./jit_test.py --tbpl -j4 ../build-debug/dist/bin/js

TIMEOUTS:
    --ion-eager --ion-offthread-compile=off js/src/jit-test/tests/ion/inlining/TypedObject-TypeDescrIsArrayType-unknown.js
    --ion-eager --ion-offthread-compile=off --non-writable-jitcode --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads js/src/jit-test/tests/ion/inlining/TypedObject-TypeDescrIsArrayType-unknown.js
    --ion-eager --ion-offthread-compile=off js/src/jit-test/tests/ion/inlining/TypedObject-TypeDescrIsArrayType.js
    --ion-eager --ion-offthread-compile=off --non-writable-jitcode --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads js/src/jit-test/tests/ion/inlining/TypedObject-TypeDescrIsArrayType.js

These tests have short bounded loops and should run in no time, suggesting a compiler/assembler bug.
With no flags or --no-threads the -unknown test runs in about 1.9s on the Jetson.

The JIT crunches a bunch of self-hosted code but very little of the test case code, and there appears to be a long stream of invalidations when turning on --ion-eager.

I think I wrote these tests back in the PJS days to test inlining of selfhosted TypedObject subroutines, they may not be representative of anything real.  I'll start a test to see if it ever finishes.
With --ion-eager --no-threads it runs for 4m46s, but it does finish :)
And 2m28s in the simulator on my AMD system, so it's probably just very slow.

Will contemplate whether the tests are worthwhile keeping around at all, or if they should at least have their loop counts reduced significantly...
Created attachment 8676116 [details] [diff] [review]
bug1203595-manual-tests.patch

This appears to be a good match for manual-tests, so just move the test cases.
Assignee: nobody → lhansen
Status: NEW → ASSIGNED
Attachment #8676116 - Flags: review?(jwalden+bmo)

Comment 5

3 years ago
Comment on attachment 8676116 [details] [diff] [review]
bug1203595-manual-tests.patch

Review of attachment 8676116 [details] [diff] [review]:
-----------------------------------------------------------------

Am I reading this right?

* -unknown.js is ~O(200,000)
* .js is ~O(100,000)

And the reason these are timeouty is that we run in baseline for ~999 iterations and don't Ion because try/catch, or even no-jit for 1000 iterations.  And that takes forever.  Right?

It would be nice to keep having these tests, which do seem valid, and only are really slow if no JIT.  Is there no way we can trim test size here to be always runnable?  If not, okay, but it would be nice to keep this testing.
Attachment #8676116 - Flags: review?(jwalden+bmo) → review+
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #5)
> Comment on attachment 8676116 [details] [diff] [review]
> bug1203595-manual-tests.patch
> 
> Review of attachment 8676116 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Am I reading this right?
> 
> * -unknown.js is ~O(200,000)
> * .js is ~O(100,000)

Yes, I think that's correct.

> And the reason these are timeouty is that we run in baseline for ~999
> iterations and don't Ion because try/catch, or even no-jit for 1000
> iterations.  And that takes forever.  Right?

I honestly don't know exactly why they take forever with --ion-eager.  There's no try-catch in the non-unknown case so that can't explain all of what's going on.  I assume that we keep recompiling because the type information keeps changing and/or we keep bailing out and invalidating, and that this just takes an eternity (note, only fails for --ion-eager --ion-offthread-compile=off).

> It would be nice to keep having these tests, which do seem valid, and only
> are really slow if no JIT.  Is there no way we can trim test size here to be
> always runnable?  If not, okay, but it would be nice to keep this testing.

The key problem here is that if we don't run enough to trigger inlining then we're not testing code generation for the inlined primitive, so manually verifying that the primitive is being inlined is really required.  And running with --ion-eager is probably a silly idea here, since inlining will depend on type information.

I think I will still move these, but I'll beef up the comments a little bit to explain exactly what's going on.
https://hg.mozilla.org/mozilla-central/rev/e8906e5b8819
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.