Bugzilla

Here is a perfherder comparison with `-ftrivial-auto-var-init=pattern` enabled on an opt build.

https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=ef2d1eaa5a80d405df665726cc3e6497289db79d&newProject=try&newRevision=7f330cc417d914f6fd6a0107307884712a5bca7b&framework=13&page=1

Additional notes:

- In a recent fuzzing collaboration meeting it was mentioned that efforts to run MSan instrumented builds of Chromium will likely not continue. Comment #6 has a link to the Chromium bug to enable `-ftrivial-auto-var-init=pattern`

- MSan and Valgrind are not reasonable methods of identifying issues. MSan would required a huge initial investment to get Firefox and all of it's dependencies built and instrumented and would require ongoing maintenance (and as mentioned above is being moved away from by other vendors). Valgrind requires a special build (which is no longer maintained on TC) and requires constant suppression list maintenance. It also adds an unreasonable runtime performance overhead that makes fuzzing much less effective. Both methods depend on test suites and fuzzing to identify issues.

- Enabling `-ftrivial-auto-var-init=pattern` should not have ongoing development costs and does not rely on test suites and fuzzing to identify issues to keep users safe. It mitigates risks without treating uninitialized memory usage as defined behavior (preventing developer for actively relying on it).

- Forced initialization *should* be optimized out when using optimization levels >`0` if memory is properly initialized before use.

- `no-opt` builds will suffer a higher performance regression (as mentioned previously) and should be excluded for the list of builds enabling this flag.



Questions that I think need to be answered before moving forward are:

- What is the threshold or upper limit of the acceptable performance regression?

- How can the performance regressions identified by the above perfherder link be investigated further?

- Are there areas of the code that we know should be excluded?

- Would it be reasonable to enable for Nightly and early Beta builds? This would help shake out any existing latent or intermittent crashes dues to uninitialized memory usage.
- - Would this give us any additional performance metrics?
- - Should we start on a single platform?

Here is a perfherder comparison with `-ftrivial-auto-var-init=pattern` enabled on an opt build.

https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=ef2d1eaa5a80d405df665726cc3e6497289db79d&newProject=try&newRevision=7f330cc417d914f6fd6a0107307884712a5bca7b&framework=13&page=1

Additional notes:

- In a recent fuzzing collaboration meeting it was mentioned that efforts to run MSan instrumented builds of Chromium will likely not continue. Comment #6 has a link to the Chromium bug to enable `-ftrivial-auto-var-init=pattern`

- MSan and Valgrind are not reasonable methods of identifying issues. MSan would required a huge initial investment to get Firefox and all of it's dependencies built and instrumented and would require ongoing maintenance (and as mentioned above is being moved away from by other vendors). Valgrind requires a special build (which is no longer maintained on TC) and requires constant suppression list maintenance. It also adds an unreasonable runtime performance overhead that makes fuzzing much less effective. Both methods depend on test suites and fuzzing to identify issues.

- Enabling `-ftrivial-auto-var-init=pattern` should not have ongoing development costs and does not rely on test suites and fuzzing to identify issues to keep users safe. It mitigates risks without treating uninitialized memory usage as defined behavior (preventing developer from actively relying on it).

- Forced initialization *should* be optimized out when using optimization levels >`0` if memory is properly initialized before use.

- `no-opt` builds will suffer a higher performance regression (as mentioned previously) and should be excluded from the list of builds enabling this flag.



Questions that I think need to be answered before moving forward are:

- What is the threshold or upper limit of the acceptable performance regression?

- How can the performance regressions identified by the above perfherder link be investigated further?

- Are there areas of the code that we know should be excluded?

- Would it be reasonable to enable for Nightly and early Beta builds? This is only meant as an alternative if enabling for all channels is for some reason not an option. This would help shake out any existing latent or intermittent crashes dues to uninitialized memory usage. 
- - Would this give us any additional performance metrics?
- - Should we start on a single platform?