Re: Frame Pointer Omission Unconditionally Disabled on Win32

[Aaron Klotz]

This is fantastic news! I hope this sticks!

On 1/12/2017 2:12 PM, Eric Rahm wrote:

As of landing bug 1322735 [1], we now unconditionally disable frame pointer
omission (FPO) on all win32 builds. FPO was already disabled on
nightly/aurora builds as a side-effect of having profiling enabled, but
will now be disabled in beta (and release eventually) after the next
uplift.

Please note: This does not mean profiling is always enabled, that's still
controlled by the --enable-profiling switch.

The main motivation for this is to get usable crash stacks via telemetry
(see bug 1280477 [2])  without the need to have users submit full crash
reports. Comment 0 in bug 1322735 [1] provides further details and analysis.

One thing we want to look out for are talos regressions once this hits
beta, after initial testing on try we determined the few minor regressions
are an acceptable trade off [3].

As a nice side effect we were able to remove the |MOZ_STACKWALKING| define.
Please don't use that anymore.

-e

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322735
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1280477
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1322735#c12
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Frame Pointer Omission Unconditionally Disabled on Win32

[Eric Rahm]

As of landing bug 1322735 [1], we now unconditionally disable frame pointer
omission (FPO) on all win32 builds. FPO was already disabled on
nightly/aurora builds as a side-effect of having profiling enabled, but
will now be disabled in beta (and release eventually) after the next
uplift.

Please note: This does not mean profiling is always enabled, that's still
controlled by the --enable-profiling switch.

The main motivation for this is to get usable crash stacks via telemetry
(see bug 1280477 [2])  without the need to have users submit full crash
reports. Comment 0 in bug 1322735 [1] provides further details and analysis.

One thing we want to look out for are talos regressions once this hits
beta, after initial testing on try we determined the few minor regressions
are an acceptable trade off [3].

As a nice side effect we were able to remove the |MOZ_STACKWALKING| define.
Please don't use that anymore.

-e

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322735
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1280477
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1322735#c12
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] Intent to vendor Servo in mozilla-central

[Bobby Holley]

On Wed, Jan 11, 2017 at 10:48 PM, Henri Sivonen 
wrote:

> On Wed, Jan 11, 2017 at 3:04 PM, Ted Mielczarek 
> wrote:
> > On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote:
> >> Does that mean that crates under third_party/rust/ are going to have
> >> their entire histories imported in the future? Currently, they only
> >> have vendoring-time snapshots.
> >
> > I'm unaware of any plans to do this. I'd expect us to have a distinction
> > between:
> > 1) Crates where Mozilla is the primary author but the repository of
> > record is somewhere else like GitHub (like Servo).
>
> (I'm writing a crate that I expect to be categorized like this in the
> future, which is why I'm interested.)
>
> > These will probably
> > be vendored specially into somewhere other than third_party/rust as
> > Servo is. There are other non-Rust projects that want this as well, such
> > as Azure (the graphics library) and devtools.
> ...
> > 3) Crates where Mozilla is not the primary author, pulled in as
> > dependencies from crates.io. These will continue to be vendored into
> > third_party/rust. Note that crates.io currently doesn't require crates
> > to specify a VCS repository or revision or anything like that, so I'm
> > not sure it's completely tractable to vendor these dependencies with
> > full history anyway.
>
> Most crates currently under third_party/rust/ are already show at
> least one Mozilla employee as a co-owner on crates.io (and, I'm
> guessing, primary author), so at present, we've already used process
> for category #3 for crates that arguably are category #1.
>
> I'm unconvinced that it makes sense to distinguish between category #1
> and category #3 in terms of placement in the m-c directory structure
> on people org chart grounds. I can see a technical case for placing
> history-imported and history-not-imported crates differently in the
> m-c directory structure, though, but it's not immediately obvious (to
> me) that people org chart situation should be the deciding factor in
> whether it's worthwhile to import the history of a given crate.
>

Yeah, I think the actual distinction is that we're doing special work for
servo (because we want to import history, and because we want to be able to
commit to it directly in m-c), whereas the stuff in third_party/rust is
what gets vendored automatically based on the crates.io dependency graph of
Gecko's Cargo.toml.

bholley


>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: forward declarations vs includes

[Gabriele Svelto]

On 12/01/2017 09:05, Mike Hommey wrote:
> +1
> 
> The sad part is that it's not followed enough.

The include hell [1] bug hasn't seem some action in a while. We might
set some time aside to do a bit of cleanup on the most commonly used
headers. I remember that the last time we did a significant push like
this we shed a lot of unnecessary stuff and improved build times measurably.

 Gabriele

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=includehell




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: forward declarations vs includes

[Mike Hommey]

On Thu, Jan 12, 2017 at 02:42:52AM -0500, Boris Zbarsky wrote:
> On 1/12/17 2:30 AM, gsquel...@mozilla.com wrote:
> > This way all users of SomeClass only need to include SomeClass.h, not 
> > SomeType.h, when they want to call SomeClass::foo.
> 
> They don't need to have SomeType.h included merely to call SomeClass::foo.
> They have the forward-declaration in scope, so they can pass along SomeType*
> values they get from somewhere, and don't even have to forward-declare it
> themselves to do so.  e.g. this would be a perfectly sane consumer of
> SomeClass:
> 
>   #include "SomeClass.h"
>   #include "SomeOtherClass.h" // also forward-declares SomeType
> 
>   void PassLongFoo(SomeClass* inst)
>   {
> inst->foo(SomeOtherClass::getSomeType());
>   }
> 
> where SomeOtherClass has a static getSomeType() returning SomeType*. None of
> this requires any of the files involved to include SomeType.h.
> 
> What _does_ require including SomeType.h is if you plan to construct a
> SomeType, or manipulate SomeType instances in some way.  But in that case,
> you really should be including SomeType.h yourself instead of relying on
> SomeClass to do it for you, in my opinion.
> 
> > I can see how nice this can be for users of SomeClass.
> 
> Until SomeClass stops using SomeType and those users stop compiling because
> they are still doing things with it but no longer getting the include
> courtesy of SomeClass.  This is especially pernicious with unified
> compilation, because it can take some time to notice.
> 
> > So I personally still prefer the coding style as is
> 
> I do too.

+1

The sad part is that it's not followed enough.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform