Closed Bug 1524337 Opened 5 years ago Closed 5 years ago

Use moz.configure for Nightly flags

Categories

(Core :: JavaScript: WebAssembly, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: bbouvier, Assigned: bbouvier)

Details

Attachments

(3 files)

This should give a few advantages:

  • no need to define the defines in several files, it should propagate everywhere
  • gives you --enable/--disable configure line options for free, with associated help (we could have --enable-wasm-gc, --enable-wasm-reftypes, etc.)
  • build peers will like us more

This got a bit bigger than just wasm (it also includes typed objects now), so updating title.

Assignee: nobody → bbouvier
Status: NEW → ASSIGNED
Summary: Use moz.configure for ENABLE_WASM_GC/REFTYPES → Use moz.configure for Nightly flags
Pushed by bbouvier@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/86c5f309b369
Rename ENABLE_BINARYDATA to ENABLE_TYPED_OBJECTS and use moz.configure; r=luke
https://hg.mozilla.org/integration/mozilla-inbound/rev/424868162298
Use moz.configure for the WebAssembly bulk memory proposal; r=luke
https://hg.mozilla.org/integration/mozilla-inbound/rev/2d7295e1d723
Move WebAssembly reftypes/gc configuration to moz.configure; r=luke
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

== Change summary for alert #19761 (as of Mon, 04 Mar 2019 08:26:52 GMT) ==

Improvements:

11% Base Content JS windows10-64 pgo stylo 5,090,648.00 -> 4,505,718.67
7% Base Content JS windows10-64 pgo stylo 5,092,542.00 -> 4,719,318.67

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=19761

This should not have brought any improvements of some sort, this is weird. (Same thing happened with bug 1527861 which landed in the same batch, where there were improvements on ARM and aarch64)

Trying to understand what's going on here. We were using if CONFIG['NIGHTLY_BUILD'] before, and this has been moved to milestone.is_nightly in moz.configure files.

Nathan, can it happen that these two options are not in sync? (that is, one can be true while the other isn't, or conversely)
If so, then what could have happened is that using milestone.is_nightly is true less often that CONFIG['NIGHTLY_BUILD'] is, which would mean some things got disabled on these builds, making runtime faster (because initialization of JS globals, etc.).

Flags: needinfo?(nfroyd)

I think what's going on here is that the alert from comment 7 is flagging the wrong bug. If you look at the graph:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=mozilla-inbound,1684832,1,4&zoom=1550066081081.8071,1550422889250.3052,4000000,5309701.492537313

The drop is not related to this code landing; it looks more like bug 1433007 landing (at least if you look at the same metric on autoland, not mozilla-inbound), which makes a lot more sense:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=mozilla-inbound,1684832,1,4&series=autoland,1685354,1,4&zoom=1550077437296.7034,1550364217630.0366,4000000,5264925.373134328

The graph does make it look like this bug produced a small blip, which I don't really understand, but at least the big change is easier to understand...?

Flags: needinfo?(nfroyd)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: