Enable TI and IonMonkey for chrome script by default

RESOLVED FIXED in mozilla30

Status

()

Core
JavaScript Engine
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: till, Assigned: till)

Tracking

unspecified
mozilla30
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
What it says on the tin. Testing of bug 907201 has not shown any regressions, so we should be good here. (Hopefully) final try push coming up.
(Assignee)

Comment 1

4 years ago
Created attachment 820210 [details] [diff] [review]
Enable TI and IonMonkey for chrome script by default
Attachment #820210 - Flags: review?(jdemooij)
(Assignee)

Comment 2

4 years ago
https://tbpl.mozilla.org/?tree=Try&rev=fa4a90d2dd57
(Assignee)

Comment 3

4 years ago
Let's do this with less bustage on the mercurial queue: https://tbpl.mozilla.org/?tree=Try&rev=5eeebc5c7c1b
Comment on attachment 820210 [details] [diff] [review]
Enable TI and IonMonkey for chrome script by default

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

Nice :)
Attachment #820210 - Flags: review?(jdemooij) → review+
(Assignee)

Comment 5

4 years ago
Sadly, the xpcshell-test failure from the try run is real. The test_unique.js test crashes. And because things would be too simple otherwise, it doesn't crash when I run it under gdb. Jandem, can you take a look at the crash[1] and tell me how best to investigate this?


[1]: https://tbpl.mozilla.org/php/getParsedLog.php?id=29602109&tree=Try#error1
Flags: needinfo?(jdemooij)

Updated

4 years ago
Depends on: 931861
It's an xpcshell signal handler issue, filed bug 931861.
Flags: needinfo?(jdemooij)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 911970
I pushed this patch to Try again and I'm getting browser-chrome nsGlobalWindow leaks. Will see if I can reproduce this locally.

https://tbpl.mozilla.org/?tree=Try&showall=1&rev=c47ae63c9c06
(In reply to Jan de Mooij [:jandem] from comment #8)
> I pushed this patch to Try again and I'm getting browser-chrome
> nsGlobalWindow leaks. Will see if I can reproduce this locally.

I can reproduce it locally when I run a single test, even without the patch, so it's likely a pre-existing issue. With help from :smaug I'm still trying to track it down.

I wrote a patch to fix xpcshell (bug 931861) and it's green now [0] so hopefully once we fix the BC leaks this will be good to go...

[0] https://tbpl.mozilla.org/?tree=Try&rev=a6a2b1fbf40d
I'm trying to track down the Linux-only, opt-only Mochitest-BC nsGlobalWindow leaks when I turn on TI for chrome, but I can't reproduce them locally so I have to use Try.

Unfortunately the BC suite takes more than an hour to run so this takes a lot of time :( But at least it's not a Win32 PGO build or an intermittent failure...
More info: with Baseline disabled, it's green. Baseline enabled without attaching IC stubs is also green. So there's likely an IC stub that's keeping stuff alive. Will try to narrow it down with more Try pushes...

Updated

3 years ago
Depends on: 970645
Bug 970645 fixes the Linux Opt nsGlobalWindow leaks I saw on Try. I also posted a patch for the xpcshell issue, bug 931861. Will do another Try push once these bugs are fixed.

Updated

3 years ago
Depends on: 832437
Yet another problem: a Linux-only profiler assert with Mochitest-BC in debug builds. With the patches in bug 832437 and bug 931861 everything is finally green on Linux x64:

https://tbpl.mozilla.org/?tree=Try&rev=c641fd52bec4
https://hg.mozilla.org/integration/mozilla-inbound/rev/3916979b9c1c
https://hg.mozilla.org/mozilla-central/rev/3916979b9c1c
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.