mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-23 21:01:08 +00:00
Bug 1750450 - Fix 'Non-consecutive header level increase' DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D165655
This commit is contained in:
Sylvestre Ledru
parent
a1b0f4d471
commit
317aabf25e
@ -5,25 +5,25 @@ Onboarding flow comprises of entire flow users have after Firefox has successful
|
||||
For new users, the first instance of new tab shows relevant messaging on about:welcome. For existing users, an upgrade dialog with release highlights is shown on major release upgrades.
|
||||
|
||||
|
||||
### New User Onboarding
|
||||
## New User Onboarding
|
||||
|
||||
A full-page multistep experience that shows up on first run since Fx80 with `browser.aboutwelcome.enabled` pref as `true`. Setting `browser.aboutwelcome.enabled` to `false` takes user to about:newtab and hides about:welcome.
|
||||
|
||||
#### Default values
|
||||
### Default values
|
||||
|
||||
Multistage proton onboarding experience is live since Fx89 and its major variations are:
|
||||
|
||||
##### Zero onboarding
|
||||
#### Zero onboarding
|
||||
|
||||
No about:welcome experience is shown (users see about:newtab during first run).
|
||||
|
||||
Testing instructions: Set `browser.aboutwelcome.enabled` to `false` in about:config
|
||||
|
||||
##### Proton
|
||||
#### Proton
|
||||
|
||||
A full-page multistep experience that shows a large splash screen and several subsequent screens. See [Default experience variations](#default-experience-variations) for more information.
|
||||
|
||||
##### Return to AMO (RTAMO)
|
||||
#### Return to AMO (RTAMO)
|
||||
|
||||
Special custom onboarding experience shown to users when they try to download an addon from addons.mozilla.org but don’t have Firefox installed. This experience allows them to install the addon they were trying to install directly from a button on RTAMO.
|
||||
|
||||
@ -35,13 +35,13 @@ Testing instructions:
|
||||
- Click Targeting -> Attribution -> Force Attribution
|
||||
- Open about:welcome, should display RTAMO page
|
||||
|
||||
#### General capabilities
|
||||
### General capabilities
|
||||
- Run experiments and roll-outs through Nimbus (see [FeatureManifests](https://searchfox.org/mozilla-central/rev/5e955a47c4af398e2a859b34056017764e7a2252/toolkit/components/nimbus/FeatureManifest.js#56)), only windows is supported. FeatureConfig (from prefs or experiments) has higher precedence to defaults. See [Default experience variations](#default-experience-variations)
|
||||
- AboutWelcomeDefaults methods [getDefaults](https://searchfox.org/mozilla-central/rev/81c32a2ea5605c5cb22bd02d28c362c140b5cfb4/browser/components/newtab/aboutwelcome/lib/AboutWelcomeDefaults.jsm#539) and [prepareContentForReact](https://searchfox.org/mozilla-central/rev/81c32a2ea5605c5cb22bd02d28c362c140b5cfb4/browser/components/newtab/aboutwelcome/lib/AboutWelcomeDefaults.jsm#566) have dynamic rules which are applied to both experiments and default UI before content is shown to user.
|
||||
- about:welcome only shows up for users who download Firefox Beta or release (currently not enabled on Nightly)
|
||||
- [Enterprise builds](https://searchfox.org/mozilla-central/rev/5e955a47c4af398e2a859b34056017764e7a2252/browser/components/enterprisepolicies/Policies.jsm#1385) can turn off about:welcome by setting the browser.aboutwelcome.enabled preference to false.
|
||||
|
||||
#### Default experience variations
|
||||
### Default experience variations
|
||||
In order of precedence:
|
||||
- Has AMO attribution
|
||||
- Return to AMO
|
||||
@ -52,16 +52,16 @@ In order of precedence:
|
||||
- Import screen allows user to import password, bookmarks and browsing history from previous browser.
|
||||
- Set a theme lets users personalize Firefox with a theme.
|
||||
|
||||
### Upgrade Dialog
|
||||
## Upgrade Dialog
|
||||
Upgrade Dialog was first introduced in Fx89 with MR1 release. It replaces whatsnew tab with an upgrade modal explaining proton changes, setting Firefox as default and/or pinning, and allowing theme change.
|
||||
|
||||
#### Feature Details:
|
||||
### Feature Details:
|
||||
- Hides whatsnew tab on release channel when Upgrade Modal is shown
|
||||
- Modal dialog appears on major version upgrade to 89 for MR1
|
||||
- It’s a window modal preventing access to tabs and other toolbar UI
|
||||
- Support desired content and actions on each screen. For MR1 initial screen explains proton changes, highlight option to set Firefox as default and pin. Subsequent screen allows theme changes.
|
||||
|
||||
#### Testing Instructions:
|
||||
### Testing Instructions:
|
||||
- In about:config, set:
|
||||
- `browser.startup.homepage_override.mstone` to `88.0` . The dialog only shows after it detects a major upgrade and need to set to 88 to trigger MR1 upgrade dialog.
|
||||
- Ensure pref `browser.startup.upgradeDialog.version` is empty. After the dialog shows, `browser.startup.upgradeDialog.version` remembers what version of the dialog to avoid reshowing.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
For a more in-depth explanation of JEXL syntax you can read the [Normady project docs](https://mozilla.github.io/normandy/user/filters.html?highlight=jexl).
|
||||
|
||||
### How to write JEXL targeting expressions
|
||||
## How to write JEXL targeting expressions
|
||||
A message needs to contain the `targeting` property (JEXL string) which is evaluated against the provided attributes.
|
||||
Examples:
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ for more information about what methods are available.
|
||||
|
||||
Preferences specific to the Discovery Stream are nested under the sub-branch `browser.newtabpage.activity-stream.discoverystream` (with the exception of `browser.newtabpage.blocked`).
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.flight.blocks`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.flight.blocks`
|
||||
|
||||
- Type: `string (JSON)`
|
||||
- Default: `{}`
|
||||
@ -89,7 +89,7 @@ Preferences specific to the Discovery Stream are nested under the sub-branch `br
|
||||
|
||||
Not intended for user configuration, but is programmatically updated. Used for tracking blocked flight IDs when a user dismisses a SPOC. Keys are flight IDs. Values don't have a specific meaning.
|
||||
|
||||
#### `browser.newtabpage.blocked`
|
||||
### `browser.newtabpage.blocked`
|
||||
|
||||
- Type: `string (JSON)`
|
||||
- Default: `null`
|
||||
@ -97,7 +97,7 @@ Not intended for user configuration, but is programmatically updated. Used for t
|
||||
|
||||
Not intended for user configuration, but is programmatically updated. Used for tracking blocked story IDs when a user dismisses one. Keys are story IDs. Values don't have a specific meaning.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.config`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.config`
|
||||
|
||||
- Type `string (JSON)`
|
||||
- Default:
|
||||
@ -121,7 +121,7 @@ Not intended for user configuration, but is programmatically updated. Used for t
|
||||
- `layout_endpoint` (string): The URL for a remote layout definition that will be used if `hardcoded_layout` is `false`.
|
||||
- `unused_key` (string): This is not set by default and is unused by this codebase. It's a standardized way to differentiate configurations to prevent experiment participants from being unenrolled.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.enabled`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.enabled`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: `true`
|
||||
@ -129,7 +129,7 @@ Not intended for user configuration, but is programmatically updated. Used for t
|
||||
|
||||
When this is set to `true` the Discovery Stream experience will show up if `enabled` is also `true` on `browser.newtabpage.activity-stream.discoverystream.config`. Otherwise the old Activity Stream experience will be shown.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.endpointSpocsClear`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.endpointSpocsClear`
|
||||
|
||||
- Type: `string (URL)`
|
||||
- Default: `https://spocs.getpocket.com/user`
|
||||
@ -137,7 +137,7 @@ When this is set to `true` the Discovery Stream experience will show up if `enab
|
||||
|
||||
Endpoint for when a user opts-out of sponsored content to delete the corresponding data from the ad server.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.endpoints`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.endpoints`
|
||||
|
||||
- Type: `string (URLs, CSV)`
|
||||
- Default: `https://getpocket.cdn.mozilla.net/,https://spocs.getpocket.com/`
|
||||
@ -145,7 +145,7 @@ Endpoint for when a user opts-out of sponsored content to delete the correspondi
|
||||
|
||||
A list of endpoints that are allowed to be used by Discovery Stream for remote content (eg: story metadata) and configuration (eg: remote layout definitions for experimentation).
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.hardcoded-basic-layout`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.hardcoded-basic-layout`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: `false`
|
||||
@ -153,7 +153,7 @@ A list of endpoints that are allowed to be used by Discovery Stream for remote c
|
||||
|
||||
If this is `false` the default hardcoded layout is used, and if it's `true` then an alternate hardcoded layout (that currently simulates the older AS experience) is used.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.rec.impressions`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.rec.impressions`
|
||||
|
||||
- Type: `string (JSON)`
|
||||
- Default: `{}`
|
||||
@ -161,7 +161,7 @@ If this is `false` the default hardcoded layout is used, and if it's `true` then
|
||||
|
||||
Programmatically generated hash table where the keys are recommendation IDs and the values are timestamps representing the first impression.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.spoc.impressions`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.spoc.impressions`
|
||||
|
||||
- Type: `string (JSON)`
|
||||
- Default: `{}`
|
||||
@ -169,7 +169,7 @@ Programmatically generated hash table where the keys are recommendation IDs and
|
||||
|
||||
Programmatically generated hash table where the keys are sponsored content IDs and the values are arrays of timestamps for every impression.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.locale-list-config`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.locale-list-config`
|
||||
|
||||
- Type: `string (CSV, locales)`
|
||||
- Default: `null`
|
||||
@ -177,7 +177,7 @@ Programmatically generated hash table where the keys are sponsored content IDs a
|
||||
|
||||
A comma separated list of locales that by default have stories enabled in newtab. It overrides what might be in region-stories-config. So if I set this to "en-US,en-CA,en-GB", all users with a English browser would see newtab stories, even if their region was not in region-stories-config list.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.region-stories-config`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.region-stories-config`
|
||||
|
||||
- Type: `string (CSV, regions)`
|
||||
- Default: `US,DE,CA,GB,IE,CH,AT,BE`
|
||||
@ -185,7 +185,7 @@ A comma separated list of locales that by default have stories enabled in newtab
|
||||
|
||||
A comma separated list of geos that by default have stories enabled in newtab. It matches the client's geo with that list, then looks for a matching locale.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.region-spocs-config`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.region-spocs-config`
|
||||
|
||||
- Type: `string (CSV, regions)`
|
||||
- Default: `US,CA,DE`
|
||||
@ -193,7 +193,7 @@ A comma separated list of geos that by default have stories enabled in newtab. I
|
||||
|
||||
A comma separated list of geos that by default have spocs enabled in newtab. It matches the client's geo with that list.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.region-layout-config`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.region-layout-config`
|
||||
|
||||
- Type: `string (CSV, regions)`
|
||||
- Default: `US,CA,GB,DE,IE,CH,AT,BE`
|
||||
@ -201,7 +201,7 @@ A comma separated list of geos that by default have spocs enabled in newtab. It
|
||||
|
||||
A comma separated list of geos that have 7 rows of stories enabled in newtab. It matches the client's geo with that list.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.region-basic-layout`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.region-basic-layout`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: false
|
||||
@ -209,7 +209,7 @@ A comma separated list of geos that have 7 rows of stories enabled in newtab. It
|
||||
|
||||
If this is `true` newtabs with stories enabled see 1 row. It is set programmatically based on the result from region-layout-config.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.spocs-endpoint`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.spocs-endpoint`
|
||||
|
||||
- Type: `string (URL)`
|
||||
- Default: `null`
|
||||
@ -217,7 +217,7 @@ If this is `true` newtabs with stories enabled see 1 row. It is set programmatic
|
||||
|
||||
Override to specify endpoint for SPOCs. Will take precedence over remote and hardcoded layout SPOC endpoints.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.personalization.version`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.personalization.version`
|
||||
|
||||
- Type: `integer`
|
||||
- Default: `1`
|
||||
@ -225,7 +225,7 @@ Override to specify endpoint for SPOCs. Will take precedence over remote and har
|
||||
|
||||
This controls what version of personalization we should use to score newtab stories.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.personalization.modelKeys`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.personalization.modelKeys`
|
||||
|
||||
- Type: `string (CSV)`
|
||||
- Default: `nb_model_arts_and_entertainment, nb_model_autos_and_vehicles, nb_model_beauty_and_fitness, nb_model_blogging_resources_and_services, nb_model_books_and_literature, nb_model_business_and_industrial, nb_model_computers_and_electronics, nb_model_finance, nb_model_food_and_drink, nb_model_games, nb_model_health, nb_model_hobbies_and_leisure, nb_model_home_and_garden, nb_model_internet_and_telecom, nb_model_jobs_and_education, nb_model_law_and_government, nb_model_online_communities, nb_model_people_and_society, nb_model_pets_and_animals, nb_model_real_estate, nb_model_reference, nb_model_science, nb_model_shopping, nb_model_sports, nb_model_travel`
|
||||
@ -233,7 +233,7 @@ This controls what version of personalization we should use to score newtab stor
|
||||
|
||||
This is a configuration for personalization version 2. It is a list of topics the algorithm uses to score stories by.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.recs.personalized`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.recs.personalized`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: false
|
||||
@ -241,7 +241,7 @@ This is a configuration for personalization version 2. It is a list of topics th
|
||||
|
||||
This controls if newtab story personalization includes regular stories or not. See spocs.personalized for sponsored content.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.spocs.personalized`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.spocs.personalized`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: true
|
||||
@ -249,7 +249,7 @@ This controls if newtab story personalization includes regular stories or not. S
|
||||
|
||||
This controls if newtab story personalization includes sponsored content or not. See recs.personalized for regular stories.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.discoverystream.isCollectionDismissible`
|
||||
### `browser.newtabpage.activity-stream.discoverystream.isCollectionDismissible`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: true
|
||||
@ -257,7 +257,7 @@ This controls if newtab story personalization includes sponsored content or not.
|
||||
|
||||
This controls if newtab story collections are dismissible or not.
|
||||
|
||||
#### `browser.newtabpage.activity-stream.feeds.section.topstories`
|
||||
### `browser.newtabpage.activity-stream.feeds.section.topstories`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: true
|
||||
@ -265,7 +265,7 @@ This controls if newtab story collections are dismissible or not.
|
||||
|
||||
This controls if the user should see newtab stories or not. It is set by the user via about:preferences#home
|
||||
|
||||
#### `browser.newtabpage.activity-stream.feeds.system.topstories`
|
||||
### `browser.newtabpage.activity-stream.feeds.system.topstories`
|
||||
|
||||
- Type: `boolean`
|
||||
- Default: false
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
The Network Monitor (netmonitor) shows you all the network requests Firefox makes (for example, when a page is loaded or when an XMLHttpRequest is performed) , how long each request takes, and details of each request. You can edit the method, query, header and resend the request as well. Read [more](https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/) to learn all the features and how to use the tool.
|
||||
|
||||
### UI
|
||||
## UI
|
||||
|
||||
The Network Monitor UI is built using [React](http://searchfox.org/mozilla-central/source/devtools/docs/frontend/react.md) components (in `src/components/`).
|
||||
|
||||
@ -16,7 +16,7 @@ The Network Monitor UI is built using [React](http://searchfox.org/mozilla-centr
|
||||
|
||||
We prefer stateless component (define by function) instead of stateful component (define by class) unless the component has to maintain its internal state.
|
||||
|
||||
### State
|
||||
## State
|
||||
|
||||
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ docs and we can talk about it.
|
||||
for react and redux code. The guidelines here are more general
|
||||
patterns not specific to code style.
|
||||
|
||||
### Why no JSX?
|
||||
## Why no JSX?
|
||||
|
||||
You probably already noticed we don't use JSX. The answer isn't
|
||||
complicated: we don't build our JS code, and we write directly for our
|
||||
@ -25,7 +25,7 @@ lot.
|
||||
It's not as bad as you may think! If you are used to JSX it may be an
|
||||
adjustment, but you won't miss it too much.
|
||||
|
||||
### One component per file
|
||||
## One component per file
|
||||
|
||||
Try to only put one component in a file. This helps avoid large files
|
||||
full of components, but it's also technically required for how we wrap
|
||||
@ -39,7 +39,7 @@ want to, but note that they won't be directly tested and you will have
|
||||
to use `React.createElement` or immediately wrap them in factories to
|
||||
use them.
|
||||
|
||||
### Export the component directly and create factory on import
|
||||
## Export the component directly and create factory on import
|
||||
|
||||
Modules are the way components interact. Ideally every component lives
|
||||
in a separate file and they require whatever they need. This allows
|
||||
@ -68,6 +68,6 @@ module.exports = Thing1;
|
||||
Do not export `{ Thing1 }` or anything like that. This is required for
|
||||
the factory wrapping as well as hot reloading.
|
||||
|
||||
### More to Come
|
||||
## More to Come
|
||||
|
||||
This is just a start. We will add more to this document.
|
||||
|
||||
@ -3,24 +3,24 @@
|
||||
**Build Metrics** is a catch-all term for performance measures that are
|
||||
generated by the Firefox build system and tracked by Perfherder.
|
||||
|
||||
### num_constructors
|
||||
## num_constructors
|
||||
|
||||
Number of static constructors found by the compiler in the Firefox C++
|
||||
codebase. Lower is better. Static constructors are undesirable because
|
||||
their initialization imposes an unavoidable time penalty every time
|
||||
Firefox is started.
|
||||
|
||||
### installer size
|
||||
## installer size
|
||||
|
||||
Size in bytes of the Firefox installer. Lower is better here, especially
|
||||
on space-restricted platforms like Android.
|
||||
|
||||
### build times
|
||||
## build times
|
||||
|
||||
Amount of time it takes to build Firefox in automation on a specific
|
||||
platform / configuration. Lower is better.
|
||||
|
||||
### compiler warnings
|
||||
## compiler warnings
|
||||
|
||||
Number of compiler warnings detected during a build. Lower is better.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ It is possible to collect performance profiles of the SpiderMonkey JIT using per
|
||||
|
||||
|
||||
|
||||
### Build setup
|
||||
## Build setup
|
||||
|
||||
To enable JIT profiling with perf jitdump, you must build Firefox or the JS shell with the following flag:
|
||||
|
||||
@ -13,7 +13,7 @@ To enable JIT profiling with perf jitdump, you must build Firefox or the JS shel
|
||||
ac_add_options --enable-perf
|
||||
```
|
||||
|
||||
### Environment Variables
|
||||
## Environment Variables
|
||||
|
||||
Two environment variables are available for perf JIT profiling:
|
||||
|
||||
@ -26,7 +26,7 @@ mkdir output
|
||||
export PERF_SPEW_DIR=output
|
||||
```
|
||||
|
||||
### Profiling the JS shell
|
||||
## Profiling the JS shell
|
||||
|
||||
Profiling the JS shell requires the following commands but is very straight forward.
|
||||
|
||||
@ -57,7 +57,7 @@ perf report --no-children -i jit.data
|
||||
|
||||
All of the above commands can be put into a single shell script.
|
||||
|
||||
### Profiling the Browser
|
||||
## Profiling the Browser
|
||||
|
||||
Profiling the browser is less straight forward than the shell, but the only main difference is that perf must attach to the content process while it is running.
|
||||
|
||||
@ -98,7 +98,7 @@ View the profile (--call-graph=graph,0 shows all call stacks instead of the defa
|
||||
perf report --no-children --call-graph=graph,0 -i jit.data
|
||||
```
|
||||
|
||||
### Additional Information
|
||||
## Additional Information
|
||||
|
||||
Some Linux distributions offer a "libc6-prof" package that includes frame pointers. This can help resolve symbols and call stacks that involve libc calls.
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
## GC and CC logs
|
||||
# GC and CC logs
|
||||
|
||||
Garbage collector (GC) and cycle collector (CC) logs give information
|
||||
about why various JS and C++ objects are alive in the heap. Garbage
|
||||
|
||||
@ -112,7 +112,7 @@ so it can take a while.
|
||||
|
||||
## Analyzing the Logs
|
||||
|
||||
##### Getting the PID and address of the leaking object
|
||||
### Getting the PID and address of the leaking object
|
||||
|
||||
The first step is to figure out the **PID** of the leaking process. The
|
||||
second step is to figure out **the address of the leaking object**,
|
||||
@ -143,7 +143,7 @@ If there are multiple files, you'll end up with one that looks like
|
||||
the largest `$n`, as this was recorded the latest, and so it will
|
||||
contain the least non-garbage.
|
||||
|
||||
##### Identifying the root in the cycle collector log
|
||||
### Identifying the root in the cycle collector log
|
||||
|
||||
The next step is to figure out why the cycle collector could not collect
|
||||
the window, using the `find_roots.py` script from the heapgraph
|
||||
@ -186,7 +186,7 @@ a head element and a JS object (the JS reflector of the script element).
|
||||
We need to figure out what the unknown reference is from, as that is
|
||||
where our leak really is.
|
||||
|
||||
##### Figure out what is holding the leaking object alive.
|
||||
### Figure out what is holding the leaking object alive.
|
||||
|
||||
Now we need to use the DMD heap scan logs. These contain the contents of
|
||||
every live block of memory.
|
||||
@ -258,7 +258,7 @@ This is an iterative process, where you first go through and mark off
|
||||
the things that are easily categorizable, and repeat until you have a
|
||||
small list of things to analyze.
|
||||
|
||||
##### Example analysis of block_analyzer.py results
|
||||
### Example analysis of block_analyzer.py results
|
||||
|
||||
In one debugging session where I was investigating the leak from bug
|
||||
1451985, I eventually reduced the list of entries until this was the
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
# Leak hunting strategies and tips
|
||||
|
||||
This document is old and some of the information is out-of-date. Use
|
||||
with caution.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ your code you are allocating memory.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### The basics
|
||||
## The basics
|
||||
- Opening [the memory
|
||||
tool](basic_operations.html#opening-the-memory-tool)
|
||||
- [Taking a heap
|
||||
@ -26,7 +26,7 @@ your code you are allocating memory.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### Analyzing snapshots
|
||||
## Analyzing snapshots
|
||||
|
||||
The Tree map view is new in Firefox 48, and the Dominators view is new
|
||||
in Firefox 46.
|
||||
@ -50,13 +50,13 @@ allocations are happening.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### Concepts
|
||||
## Concepts
|
||||
|
||||
- What are [Dominators](dominators.md)?
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### Example pages
|
||||
## Example pages
|
||||
|
||||
Examples used in the Memory tool documentation.
|
||||
|
||||
|
||||
@ -121,7 +121,7 @@ and also improves the performance.
|
||||
|
||||
perl -w tools/rb/filter-log.pl --object 0x00253ab0 < ./refcounts.log > my-leak.log
|
||||
|
||||
#### Linux Users
|
||||
### Linux Users
|
||||
|
||||
The log file generated on Linux system often lack function names, file
|
||||
names and line numbers. Linux users need to run a script to fix the call
|
||||
|
||||
@ -14,7 +14,7 @@ the About window; that's the Windows version.)
|
||||
If you have an older version, you will experience bugs, especially
|
||||
around symbol loading for local builds.
|
||||
|
||||
### Installation
|
||||
## Installation
|
||||
|
||||
For all versions, the tools are part of the latest [Windows 7 SDK (SDK
|
||||
Version
|
||||
@ -34,7 +34,7 @@ then restart to enable stack walking:\
|
||||
\
|
||||
`REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v DisablePagingExecutive -d 0x1 -t REG_DWORD -f`
|
||||
|
||||
### Symbol Server Setup
|
||||
## Symbol Server Setup
|
||||
|
||||
With the latest versions of the Windows Performance Toolkit, you can
|
||||
modify the symbol path directly from within the program via the Trace
|
||||
@ -65,7 +65,7 @@ not prompted for this, then something isn't configured right in your
|
||||
symbol path. (Again, make sure that the directories exist; if they
|
||||
don't, it's a silent error.)
|
||||
|
||||
### Quick Start
|
||||
## Quick Start
|
||||
|
||||
All these tools will live, by default, in C:\\Program Files\\Microsoft
|
||||
Windows Performance Toolkit. Either run these commands from there, or
|
||||
@ -100,7 +100,7 @@ using essentially the same screenshots, so go look there.
|
||||
|
||||
The 'stack' view will give results similar to shark.
|
||||
|
||||
### Heap Profiling
|
||||
## Heap Profiling
|
||||
|
||||
xperf has good tools for heap allocation profiling, but they have one
|
||||
major limitation: you can't build with jemalloc and get heap events
|
||||
@ -109,7 +109,7 @@ fragmentation, and causes memory usage to rise drastically even if only
|
||||
a small fraction of that memory is in use. However, even despite this,
|
||||
it's a useful way to track allocations/deallocations.
|
||||
|
||||
#### Capturing Heap Data
|
||||
### Capturing Heap Data
|
||||
|
||||
The \"-heap\" option is used to set up heap tracing. Firefox generates
|
||||
lots of events, so you may want to play with the
|
||||
@ -142,7 +142,7 @@ range that was selected for the summary graph; for example, something
|
||||
that's in the AOFI category was allocated before the start of the
|
||||
selected time range, but the free event happened inside.
|
||||
|
||||
### Tips
|
||||
## Tips
|
||||
|
||||
- In the summary views, the yellow bar can be dragged left and right
|
||||
to change the grouping \-- for example, drag it to the left of the
|
||||
@ -157,7 +157,7 @@ selected time range, but the free event happened inside.
|
||||
This can be done by running 'msconfig' and going to Advance
|
||||
Options from the \"Boot\" tab.
|
||||
|
||||
### Building Firefox
|
||||
## Building Firefox
|
||||
|
||||
To get good data from a Firefox build, it is important to build with the
|
||||
following options in your mozconfig:
|
||||
@ -173,7 +173,7 @@ be useful.
|
||||
|
||||
This gives us symbols.
|
||||
|
||||
### For More Information
|
||||
## For More Information
|
||||
|
||||
Microsoft's [documentation for xperf](http://msdn.microsoft.com/en-us/library/ff191077.aspx "http://msdn.microsoft.com/en-us/library/ff191077.aspx")
|
||||
is pretty good; there is a lot of depth to this tool, and you should
|
||||
|
||||
@ -20,7 +20,7 @@ an instance of `Debugger.Memory`; its inherited accessors and methods are
|
||||
described below.
|
||||
|
||||
|
||||
### Allocation Site Tracking
|
||||
## Allocation Site Tracking
|
||||
|
||||
The JavaScript engine marks each new object with the call stack at which it was
|
||||
allocated, if:
|
||||
@ -43,7 +43,7 @@ object, <code><i>dobj</i>.[allocationSite][allocation-site]</code> returns a
|
||||
allocated.
|
||||
|
||||
|
||||
### Allocation Logging
|
||||
## Allocation Logging
|
||||
|
||||
If <i>dbg</i> is a [`Debugger`][debugger-object] instance, and
|
||||
<code><i>dbg</i>.memory.[trackingAllocationSites][tracking-allocs]</code> is set
|
||||
@ -54,7 +54,7 @@ control the limit on the log's size by setting
|
||||
<code><i>dbg</i>.memory.[maxAllocationsLogLength][max-alloc-log]</code>.
|
||||
|
||||
|
||||
### Censuses
|
||||
## Censuses
|
||||
|
||||
A *census* is a complete traversal of the graph of all reachable memory items
|
||||
belonging to a particular `Debugger`'s debuggees. It produces a count of those
|
||||
@ -71,7 +71,7 @@ If <i>dbg</i> is a [`Debugger`][debugger-object] instance, then
|
||||
`<i>dbg</i>.memory` is a `Debugger.Memory` instance, which inherits the
|
||||
following accessor properties from its prototype:
|
||||
|
||||
### `trackingAllocationSites`
|
||||
## `trackingAllocationSites`
|
||||
A boolean value indicating whether this `Debugger.Memory` instance is
|
||||
capturing the JavaScript execution stack when each Object is allocated. This
|
||||
accessor property has both a getter and setter: assigning to it enables or
|
||||
@ -86,7 +86,7 @@ You can retrieve the allocation site for a given object with the
|
||||
[`Debugger.Object.prototype.allocationSite`][allocation-site] accessor
|
||||
property.
|
||||
|
||||
### `allocationSamplingProbability`
|
||||
## `allocationSamplingProbability`
|
||||
A number between 0 and 1 that indicates the probability with which each new
|
||||
allocation should be entered into the allocations log. 0 is equivalent to
|
||||
"never", 1 is "always", and .05 would be "one out of twenty".
|
||||
@ -98,12 +98,12 @@ observing the same allocations within a global's scope, the maximum
|
||||
<code>allocationSamplingProbability</code> of all the
|
||||
<code>Debugger</code>s is used.
|
||||
|
||||
### `maxAllocationsLogLength`
|
||||
## `maxAllocationsLogLength`
|
||||
The maximum number of allocation sites to accumulate in the allocations log
|
||||
at a time. This accessor can be both fetched and stored to. Its default
|
||||
value is `5000`.
|
||||
|
||||
### `allocationsLogOverflowed`
|
||||
## `allocationsLogOverflowed`
|
||||
Returns `true` if there have been more than
|
||||
[`maxAllocationsLogLength`][#max-alloc-log] allocations since the last time
|
||||
[`drainAllocationsLog`][#drain-alloc-log] was called and some data has been
|
||||
@ -130,14 +130,14 @@ Handler functions run in the same thread in which the event occurred.
|
||||
They run in the compartment to which they belong, not in a debuggee
|
||||
compartment.
|
||||
|
||||
### `onGarbageCollection(statistics)`
|
||||
## `onGarbageCollection(statistics)`
|
||||
A garbage collection cycle spanning one or more debuggees has just been
|
||||
completed.
|
||||
|
||||
The *statistics* parameter is an object containing information about the GC
|
||||
cycle. It has the following properties:
|
||||
|
||||
#### `collections`
|
||||
## `collections`
|
||||
The `collections` property's value is an array. Because SpiderMonkey's
|
||||
collector is incremental, a full collection cycle may consist of
|
||||
multiple discrete collection slices with the JS mutator running
|
||||
@ -154,7 +154,7 @@ in the `collections` array with the following form:
|
||||
Here the `timestamp` values are [timestamps][timestamps] of the GC slice's start
|
||||
and end events.
|
||||
|
||||
#### `reason`
|
||||
## `reason`
|
||||
A very short string describing the reason why the collection was
|
||||
triggered. Known values include the following:
|
||||
|
||||
@ -192,7 +192,7 @@ triggered. Known values include the following:
|
||||
* `"SHUTDOWN_CC"`
|
||||
* `"USER_INACTIVE"`
|
||||
|
||||
#### `nonincrementalReason`
|
||||
## `nonincrementalReason`
|
||||
If SpiderMonkey's collector determined it could not incrementally
|
||||
collect garbage, and had to do a full GC all at once, this is a short
|
||||
string describing the reason it determined the full GC was necessary.
|
||||
@ -203,7 +203,7 @@ Otherwise, `null` is returned. Known values include the following:
|
||||
* `"allocation trigger"`
|
||||
* `"requested"`
|
||||
|
||||
#### `gcCycleNumber`
|
||||
## `gcCycleNumber`
|
||||
The GC cycle's "number". Does not correspond to the number
|
||||
of GC cycles that have run, but is guaranteed to be monotonically
|
||||
increasing.
|
||||
@ -211,7 +211,7 @@ increasing.
|
||||
Function Properties of the `Debugger.Memory.prototype` Object
|
||||
-------------------------------------------------------------
|
||||
|
||||
### `drainAllocationsLog()`
|
||||
## `drainAllocationsLog()`
|
||||
When `trackingAllocationSites` is `true`, this method returns an array of
|
||||
recent `Object` allocations within the set of debuggees. *Recent* is
|
||||
defined as the `maxAllocationsLogLength` most recent `Object` allocations
|
||||
@ -250,7 +250,7 @@ commonly) "Object".
|
||||
When `trackingAllocationSites` is `false`, `drainAllocationsLog()` throws an
|
||||
`Error`.
|
||||
|
||||
### `takeCensus(options)`
|
||||
## `takeCensus(options)`
|
||||
Carry out a census of the debuggee compartments' contents. A *census* is a
|
||||
complete traversal of the graph of all reachable memory items belonging to a
|
||||
particular `Debugger`'s debuggees. The census produces a count of those
|
||||
@ -494,7 +494,7 @@ This section covers some areas where Firefox's actual behavior deviates from
|
||||
what one might expect from the specified behavior of the web platform.
|
||||
|
||||
|
||||
### Objects
|
||||
## Objects
|
||||
|
||||
SpiderMonkey objects usually use less memory than the naïve "table of properties
|
||||
with attributes" model would suggest. For example, it is typical for many
|
||||
@ -506,7 +506,7 @@ metadata; only property values are stored directly in the object.
|
||||
Array objects may also be optimized, if the set of live indices is dense.
|
||||
|
||||
|
||||
### Strings
|
||||
## Strings
|
||||
|
||||
SpiderMonkey has three representations of strings:
|
||||
|
||||
@ -532,7 +532,7 @@ SpiderMonkey shares some strings amongst all web pages and browser JS. These
|
||||
shared strings, called *atoms*, are not included in censuses' string counts.
|
||||
|
||||
|
||||
### Scripts
|
||||
## Scripts
|
||||
|
||||
SpiderMonkey has a complex, hybrid representation of JavaScript code. There
|
||||
are four representations kept in memory:
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
When called as a constructor, the `Debugger` object creates a new
|
||||
`Debugger` instance.
|
||||
|
||||
### `new Debugger([global, ...])`
|
||||
## `new Debugger([global, ...])`
|
||||
Create a debugger object, and apply its [`addDebuggee`][add] method to
|
||||
each of the given <i>global</i> objects to add them as the initial
|
||||
debuggees.
|
||||
|
||||
@ -6,92 +6,92 @@ This is a quick summary of all the MIR passes as of Feb 2021. The italicized pas
|
||||
|
||||
The state of the MIR after each of these passes can be visualized using [iongraph](https://github.com/sstangl/iongraph).
|
||||
|
||||
### *BuildSSA*
|
||||
## *BuildSSA*
|
||||
[Single Static Assignment](https://en.wikipedia.org/wiki/Static_single_assignment_form) is a form of IR in which every value is defined exactly once. It has several nice properties for optimization. Note: SSA is why we have phi nodes.
|
||||
|
||||
### Prune Unused Branches
|
||||
## Prune Unused Branches
|
||||
What it says on the tin: prunes away branches that are never taken.
|
||||
|
||||
### Fold Empty Blocks
|
||||
## Fold Empty Blocks
|
||||
A simple cleanup pass to get rid of empty blocks with one predecessor and one successor by folding them into their successor.
|
||||
|
||||
### Fold Tests
|
||||
## Fold Tests
|
||||
Simplifies the code generated for conditional operations. [See the comment here](https://searchfox.org/mozilla-central/rev/bd92b9b4a3c2ff022e830c1358968a84e6e69c95/js/src/jit/IonAnalysis.cpp#849-871).
|
||||
|
||||
### Split Critical Edges
|
||||
## Split Critical Edges
|
||||
In subsequent passes, we may choose to move code around. In preparation, this pass adds empty blocks along [critical edges](https://en.wikipedia.org/wiki/Control-flow_graph#Special_edges), so that we have a safe place to put those instructions.
|
||||
|
||||
### Renumber Blocks
|
||||
## Renumber Blocks
|
||||
This pass literally just reassigns block numbers.
|
||||
|
||||
### Eliminate Phis
|
||||
## Eliminate Phis
|
||||
After some of the above optimizations, some of our phi nodes may be things like `b = phi(a,a)`, which is redundant. This pass cleans those up.
|
||||
|
||||
### *Scalar Replacement*
|
||||
## *Scalar Replacement*
|
||||
If a function allocates and uses an object, but we can [prove that the object never escapes the function](https://en.wikipedia.org/wiki/Escape_analysis), then we can sometimes avoid the allocation entirely by tracking each of the object’s components (fields in C/C++; slots/elements in JS) individually.
|
||||
|
||||
### Apply types
|
||||
## Apply types
|
||||
Each type of MIR node has a [TypePolicy](https://searchfox.org/mozilla-central/rev/fd853f4aea89186efdb368e759a71b7a90c2b89c/js/src/jit/TypePolicy.h#23-35) defining what type of input it accepts. If necessary, this pass inserts (potentially fallible) conversions to guarantee that the types work out.
|
||||
|
||||
### *Alias Analysis*
|
||||
## *Alias Analysis*
|
||||
[Alias analysis](https://en.wikipedia.org/wiki/Alias_analysis) determines whether two instructions may use/modify the same memory. If they do, then they can not be reordered with respect to each other, because that could change the semantics of the program.
|
||||
|
||||
### *GVN*
|
||||
## *GVN*
|
||||
[Global Value Numbering](https://en.wikipedia.org/wiki/Value_numbering) is a classic optimization for finding places where we compute the same value multiple times, and eliminating the redundancy.
|
||||
|
||||
### *LICM*
|
||||
## *LICM*
|
||||
[Loop-Invariant Code Motion](https://en.wikipedia.org/wiki/Loop-invariant_code_motion) finds instructions in a loop that will compute the same value every time and hoists them out of the loop.
|
||||
|
||||
### Beta
|
||||
## Beta
|
||||
This is done in preparation for range analysis. This particular approach to range analysis is [taken from a paper by Gough and Klaren](https://searchfox.org/mozilla-central/rev/fd853f4aea89186efdb368e759a71b7a90c2b89c/js/src/jit/RangeAnalysis.cpp#49-108).
|
||||
|
||||
### *Range Analysis*
|
||||
## *Range Analysis*
|
||||
[A classic optimization](https://en.wikipedia.org/wiki/Value_range_analysis) that determines the possible range of values a definition can take on. Used to implement many of the following passes.
|
||||
|
||||
### De-Beta
|
||||
## De-Beta
|
||||
Remove beta nodes now that we don’t need them.
|
||||
|
||||
### RA Check UCE
|
||||
## RA Check UCE
|
||||
Check to see if range analysis has made any code eligible for Unreachable Code Elimination.
|
||||
|
||||
### Truncate Doubles
|
||||
## Truncate Doubles
|
||||
Strength-reduce double arithmetic to integer arithmetic if range analysis says it’s okay.
|
||||
|
||||
### Sink
|
||||
## Sink
|
||||
If we compute a value that will only be used along some paths, and we could recover the value if one of the other paths bailed out, then we can postpone the computation of that variable until we are sure we will need it. [More details here](https://bugzilla.mozilla.org/show_bug.cgi?id=1093674).
|
||||
|
||||
### Remove Unnecessary Bitops
|
||||
## Remove Unnecessary Bitops
|
||||
Remove bit-wise arithmetic operators that don’t do anything (like `x | 0` on integer input).
|
||||
|
||||
### Fold Linear Arithmetic Constants
|
||||
## Fold Linear Arithmetic Constants
|
||||
Fold `a + constant1 + constant2` into `a + (constant1+constant2)`.
|
||||
|
||||
### Effective Address Analysis
|
||||
## Effective Address Analysis
|
||||
This was added to ensure that we generated good code for memory accesses in asm.js.
|
||||
|
||||
### *DCE*
|
||||
## *DCE*
|
||||
[Dead code elimination](https://en.wikipedia.org/wiki/Dead_code_elimination) removes instructions whose results are never needed.
|
||||
|
||||
### *Reordering*
|
||||
## *Reordering*
|
||||
Shuffle instructions around within a block to reduce the lifetime of intermediate values and reduce register pressure. This is a relatively simple version of [instruction scheduling](https://en.wikipedia.org/wiki/Instruction_scheduling).
|
||||
|
||||
### Make loops contiguous
|
||||
## Make loops contiguous
|
||||
Reorder blocks so that all the blocks in a loop are generated in one contiguous chunk, which is good for cache locality.
|
||||
|
||||
### Edge Case Analysis (Late)
|
||||
## Edge Case Analysis (Late)
|
||||
A place to check for edge cases after code has stopped being moved around. Currently used for checking whether some instructions need to handle negative zero.
|
||||
|
||||
### *Bounds Check Elimination*
|
||||
## *Bounds Check Elimination*
|
||||
[A classic optimization](https://en.wikipedia.org/wiki/Bounds-checking_elimination) that eliminates bounds checks if we can prove at compile time that they can’t fail.
|
||||
|
||||
### FoldLoadsWithUnbox
|
||||
## FoldLoadsWithUnbox
|
||||
Loading a NaN-boxed value and then unboxing it can be slightly more efficient if we do both operations at once.
|
||||
|
||||
### Add KeepAlive Instructions
|
||||
## Add KeepAlive Instructions
|
||||
While we access the slots or elements of an object, we have to ensure that the object itself is not collected by the GC. See [bug 1160884](https://bugzilla.mozilla.org/show_bug.cgi?id=1160884).
|
||||
|
||||
### Generate LIR
|
||||
## Generate LIR
|
||||
After optimization is over, we lower our IR from MIR to LIR to do register allocation and code generation.
|
||||
|
||||
### *Allocate Registers*
|
||||
## *Allocate Registers*
|
||||
Programs can have way more variables than hardware has registers, so we have to decide which values live in which registers when. [This is a very well studied area](https://en.wikipedia.org/wiki/Register_allocation).
|
||||
|
||||
@ -5,13 +5,13 @@ In order to ensure thread safety it is important that all of the objects and int
|
||||
If you are implementing a new URI type, please make sure that none of the type's public methods change the URL.
|
||||
```
|
||||
|
||||
### Definitions
|
||||
## Definitions
|
||||
- URI - Uniform Resource Identifier
|
||||
- URL - Uniform Resource Locator
|
||||
|
||||
These two terms are used interchangeably throughout the codebase and essentially represent the same thing - a string of characters that represents a specific resource.
|
||||
|
||||
### Motivation
|
||||
## Motivation
|
||||
|
||||
While we could simply pass strings around and leave it to the final consumer to deal with it, that creates a burden for the consumer and would probably be inefficient. Instead we parse the string into a nsIURI object as soon as possible and pass that object through function calls. This allows the consumer to easily extract only the part of the string they are interested in (eg. the hostname or the path).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user