Re: Is there an e10s plan for multiple content processes?

On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X) Redacted.For.Spam@request.contact wrote: I heard that there was rumor of a plan to limit process count spawn to per-domain. But I've not seen offhand of a bug filed for it or anything else that relates to achieving more than one content

Re: The War on Warnings

On Thu, Jun 4, 2015 at 1:48 PM, Luke Wagner lwag...@mozilla.com wrote: In addition to judging noisiness by volume over a whole test run, can we also include any warning that happens on normal browser startup, new tab, and other vanilla browser operations? This has always annoyed me. Indeed.

PLDHashTable now uses automatic initialization and finalization

Hi, I changed PLDHashTable a little while back so that the allocation of entry storage happens when the first element is added, rather than when the table is initialized. This means that initialization is now infallible and cheap, which means there is no need to distinguish between an

Re: The War on Warnings

On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote: It feels like right now we have three incompatible desires: * Test lots of failure cases. * Make errors warn in debug builds on all/most frames as the failure is propagated up the callstack. * Don't warn a lot when

Re: Revisiting modelines in source files

Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc g...@mozilla.com wrote: We can mass rewrite the tree. But unless the tools to keep things consistent are easy and painless to use, this will add chaos. Chaos? There are two distinct steps here. 1. Get the style mostly consistent (e.g.

Re: Disabling the startup cache

On Sat, Jun 20, 2015 at 1:36 PM, Aaron Klotz akl...@mozilla.com wrote: I did some measurements last year at the 2014 JS workweek and it turns out that the cost of converting the omnijar's JS source to jschars during parsing is equivalent to the benefits we gain from StartupCache. Assuming

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 8:03 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I use vim, and the modelines are definitely useful to me. Same here. I'm also somebody who writes patches all over the codebase, and having the 2-space or 4-space indentation done automatically is *very* helpful. (I

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 10:07 AM, Gregory Szorc g...@mozilla.com wrote: Can we all agree that the needs of the many outweigh the needs of the few and establish a consistent and enforced C++ coding style across all of mozilla-central? There's been general consensus around this for a while now.

Re: The War on Warnings

On Wed, Jun 17, 2015 at 9:29 AM, Eric Rahm er...@mozilla.com wrote: An update on progress. I've landed bugs which should clean up ~180,000 warnings. I have bugs pending for another ~26,000. Lovely! Thank you. The log size changes are impressive. Top 40 sorted by top level directory: I

Re: Replacing PR_LOG levels

On Thu, May 28, 2015 at 4:21 PM, Chris Pearce cpea...@mozilla.com wrote: My team has been trying (and failing!) for years to get a Verbose level added to NSPR logging. Just yesterday Eric wrote (in the message immediately before this one in the thread) the following: After some back and forth

Re: Linked Data must die. (was: Linked Data and a new Browser API event)

On Wed, Jul 1, 2015 at 7:37 PM, Tantek Çelik tan...@cs.stanford.edu wrote: There *is* a pretty strong engineering consensus, in both this thread, and other threads *against* any use of JSON-LD, or anything Linked Data or otherwise rebranded RDF / Semantic Web, and for good reason. Indeed,

Re: Revisions to the Job Visibility Policy

On Mon, Jul 6, 2015 at 7:52 AM, Ryan VanderMeulen rvandermeu...@mozilla.com wrote: The tl;dr: Instead of only having binary visible or hidden states, we're adding a middle ground. A Tier 2 option is being added that allows for jobs that meet most but not all of the visibility requirements to

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

I like 'aFoo'. Nick On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should

Re: Replacing PR_LOG levels

On Sat, May 23, 2015 at 5:11 AM, Gregory Szorc g...@mozilla.com wrote: Better than a log level is an event type (possibly enumerated). I suspect that's right. Having said that, Eric is trying to clean up an existing system which is large and messy. Just fixing up the log levels is challenging

Re: Replacing PR_LOG levels

On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org wrote: Various bits of code invented a log level that was less important than debug (I would call this verbose). This was not specified in NSPR logging, but just kind of worked. With the addition of |Info| we can transition code

Largest chunks of code that are likely to be removable?

Hi, I'm wondering what the largest chunks of code there are in the codebase that are candidates for removal, i.e. probably with a bit of work but not too much. One that comes to mind is rdf/ (see https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I don't have a good understanding of

Re: Remove nsITimer.TYPE_REPEATING_PRECISE?

On Sun, Aug 2, 2015 at 10:31 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Would it be reasonable to remove nsITimer.TYPE_REPEATING_PRECISE? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1190735 for this, and a patch to do ithas r+. I thought I'd mention it here, before I land

Re: Hash table iterators, and a call for help

On Fri, Jul 24, 2015 at 2:06 PM, Philip Chee philip.c...@gmail.com wrote: Does PL_HashTableEnumerateEntries also need to be replaced? And if so what with? That function operates on PLHashTable, which is part of NSPR. (Don't confuse it with PLDHashTable, which is part of XPCOM, as are its

Re: Hash table iterators, and a call for help

On Sun, Jul 12, 2015 at 10:36 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Last week I landed patches that remove PL_DHashTableEnumerate() from the tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1180072). You should now use PLDHashTable::Iterator if you want to iterate over

Re: Hash table iterators, and a call for help

On Fri, Jul 24, 2015 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Yes please! Though IIRC

Re: Hash table iterators, and a call for help

On Mon, Jul 13, 2015 at 11:20 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: I did not see nsTHashtable and nsBasHashtable define stl style iterators for use in range-based for loops. Is this intentional? See https://bugzilla.mozilla.org/show_bug.cgi?id=1149833. Nick

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Nick ___ dev-platform mailing list

Re: Hash table iterators, and a call for help

On Sun, Jul 19, 2015 at 8:39 PM, Ting-Yu Lin t...@mozilla.com wrote: It might be worth to mention the PLDHashTable::Iterator in the hashtable guides. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Hashtables

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking wrote: > > Given that people are already feeling pressure to fix up thunderbird > code when they land patches, I can only see that pressure increasing > when you don't even need to pull a separate tree. That's more or less

Re: Merging comm-central into mozilla-central

On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking wrote: > > The question is, do we fix that friction by making collaboration > easier, or do we fix it by reducing collaboration. Yes. Merging c-c into m-c would achieve the first alternative. (And it has support from plenty of

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 6:57 PM, Mike Hommey wrote: > > - Relatedly, many codebase-wise changes (e.g. refactorings), or core API > changes tend to break comm-central. While it can be argued that it > shouldn't be platform engineers' burden to care about those, the fact >

Re: MemShrink: an ongoing initiative to reduce memory consumption

And please note that following along isn't onerous. We typically get ~3 bugs to triage per week. Nick On Wed, Nov 4, 2015 at 8:07 AM, Eric Rahm wrote: > Hi folks- > > The MemShrink project [1] has been around for several years. You may have > seen the [MemShrink] tag added to

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > What's needed here is a dependency management system that > simply builds what's needed regardless of what's changed, Otherwise known as "a proper build system". glandium and co. have been working towards that for a long

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: >> >> Eventually |mach build| should just do the right >> thing, no matter what files you've touched... > > The problem is that definitions of "right thing" differ depending on the > goal, right? I'm using the standard build

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari wrote: > > On Linux, most other recent versions of clang should work too, such as the > one you usually get from your distro, provided that the dev package for > LLVM/Clang has been installed. Is there an easy way to

Re: Decommissioning "dumbmake"

On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley wrote: > > |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari wrote: >> >> Is there an easy way to determine if that package has been installed? > > The easiest way is to turn it on in a build and see if the build succeeds. On my stock Ubuntu 15.04 box it failed... >> And if it's not

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 5:13 PM, Jeff Gilbert jgilb...@mozilla.com wrote: MSVC 2013 (which I believe is our main windows compiler right now) will error during compilation if such a shadowing issue arises. Thus, if the code compiles there, `aFoo`-`foo` is safe. I would be very surprised if GCC

Hash table iterators, and a call for help

Hi, Last week I landed patches that remove PL_DHashTableEnumerate() from the tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1180072). You should now use PLDHashTable::Iterator if you want to iterate over a PLDHashTable. The iterator is *so* much nicer -- there's none of that bundle up an

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Thu, Jul 9, 2015 at 7:01 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Arguments have the same lifetimes as locals, and the only exceptions to this apply to both args and locals. (references and pointers) Maybe I've misunderstood what you're saying here, but locals are frequently

The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

For some time we've had a moz.build option called FAIL_ON_WARNINGS. If you build with --enable-warnings-as-errors (as the test machines do) the presence of FAIL_ON_WARNINGS in a directory's moz.build files causes compiler warnings from that directory's files to be treated as errors. I.e. it

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 11:09 AM, Ehsan Akhgari wrote: >> >> Should we hold third-party code to the same warning levels as Mozilla's >> home-grown code? > > Yeah, I think in practice it's impossible to hold such code to our > standards. I agree. I wrote the following in

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 12:10 PM, Chris Peterson wrote: > > When I said we have typically suppressed third-party warnings, I meant with > CXXFLAGS += ['-Wno-whatever'] in moz.build I'm not convinced this is worth the effort for "true" third-party code. The next time we

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 10:47 AM, Chris Peterson wrote: > > In other projects I've worked on, such as closed-source commercial projects > or Chromium, third-party code has been "quarantined" in a top-level vendor > directory (called something like "third_party" [1]). Having

Re: You can now freely mix declarations and statements in all Mozilla C code

On Thu, Sep 10, 2015 at 7:01 AM, Eric Rescorla wrote: > >> Therefore, 16 years later, you can now mix statements and declarations >> freely in Mozilla C code. > > Note: this does not apply to NSS and NSPR, though those need separate > commit rights, so if you work on them you

Project Candle: an initiative to reduce power consumption

Greetings, The 2015 Platform Engineering roadmap [1] (https://wiki.mozilla.org/Platform/Roadmap) mentioned "Candle", an initiative that aims to reduce the power consumption of Firefox (desktop and Android) and Firefox OS, that sits alongside other well-known initiatives like CrashKill, CritSmash,

Re: Project Candle: an initiative to reduce power consumption

:14 AM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > Greetings, > > The 2015 Platform Engineering roadmap [1] > (https://wiki.mozilla.org/Platform/Roadmap) mentioned "Candle", an initiative > that aims to reduce the power consumption of Firefox (deskto

Re: About static analyzers on some various projects

On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari wrote: > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote: >> >> * Coverity, a proprietary tool with a great (but slow) web interface. > > Does anybody look at these regularly? I would be interested to know if they > produce

Re: About static analyzers on some various projects

On Fri, Sep 25, 2015 at 11:46 PM, Ehsan Akhgari wrote: > > Our static analysis builds can be easily triggered from the try server > (although I have been unable to get anyone interested to fix bug 1116518 to > make those builds happen on the try server by default, which

Re: Single- vs. double-precision FP in gfx types

On Tue, Nov 24, 2015 at 7:05 PM, Robert O'Callahan wrote: >> >> It still seems like, where possible, we should switch from passing >> around an nsRenderingContext or a gfxContext to passing around a >> DrawTarget. (Presumably starting from leaf functions and moving >> up.)

Re: Single- vs. double-precision FP in gfx types

On Tue, Dec 8, 2015 at 4:34 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > One interesting thing I found is that a *lot* of the functions that > take an nsRenderingContext or gfxContext do so because they end up > passing it into text run code -- gfxTextRun uses

Re: Single- vs. double-precision FP in gfx types

On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: >> >> One interesting thing I found is that a *lot* of the functions that >> take an nsRenderingContext or gfxContext do so because they end up >> passing it into text run code -- gfx

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Sun, Dec 13, 2015 at 9:17 AM, Cameron Kaiser wrote: > > This would essentially mandate, then, that Gecko can only be built on > platforms with a Rust toolchain. That may be desirable, but it would > probably bust some of the obscure Tier-3 platforms and it would

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Sun, Dec 13, 2015 at 11:28 AM, Bobby Holley wrote: >> >> I've been wondering about this. There's a big difference between (a) >> permitting Rust components (while still allowing fallback C++ >> equivalents) and (b) mandating Rust components. > > I don't know why we would

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

Sheriffs make developers' lives easier. Thank you, sheriffs. Nick On Thu, Dec 31, 2015 at 1:19 AM, Carsten Book wrote: > Hi, > > Sheriffing is not just about Checkins, Uplifts and Backouts - its also a > lot of teamwork with different Groups and our Community like Developers,

Re: Single- vs. double-precision FP in gfx types

On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: >> >> One interesting thing I found is that a *lot* of the functions that >> take an nsRenderingContext or gfxContext do so because they end up >> passing it into text run code -- gfx

Re: Single- vs. double-precision FP in gfx types

On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan wrote: >> >> One major remaining Moz2Dification step is the conversion of thebes >> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D >> equivalents. > > I think for now we should focus on replacing

Single- vs. double-precision FP in gfx types

Hi, One major remaining Moz2Dification step is the conversion of thebes types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D equivalents. But this is largely blocked by the fact that the thebes types use double-precision FP values while the Moz2D types use single-precision FP

Re: A list of easy-ish gfxContext-to-DrawTarget conversions

On Tue, Jan 12, 2016 at 4:30 PM, Jeff Gilbert wrote: > For a similar situation, we used an etherpad to allow painless > acquisition of pending todos. Good idea. I created https://public.etherpad-mozilla.org/p/EasyDrawTarget for this purpose. Nick

A list of easy-ish gfxContext-to-DrawTarget conversions

Greetings, Over the past few weeks I have spent some time doing gfxContext-to-DrawTarget conversions. (Also nsRendering-to-DrawTarget conversions, which are basically the same because nsRenderingContext is a wafer-thin wrapper around gfxContext.) The number of occurrences of gfxContext and

IXL

Hey baby, Both kids are doing IXL right now! So I renamed Keira's account -- which Zack had been using -- as Zack, and then paid $29 to get an extra account and added Keira. N ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: IXL

Sorry, this email was not meant to go to this list. (Gmail changed the auto-completion order I was accustomed to on the "address" field.) Please ignore. If anyone has the ability to remove this email from the list archives, please do so! Thanks. Nick On Fri, Jun 3, 2016 at 8:25 AM

Re: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill reports incoming

BTW, you can tell if a crash report was triggered by this new feature by looking for the presence of the "submitted from infobar" field. On Sat, Jun 4, 2016 at 2:37 AM, Ehsan Akhgari wrote: > FYI > > -- Forwarded message -- > From: Lawrence Mandel

Documentation on how to read crash reports

Hi, Do we have documentation on how to read crash reports? The only thing I have found is this page: https://support.mozilla.org/en-US/kb/helping-crashes which is not bad, but is lacking some details. I suspect there is quite a bit of crash report interpretation wisdom that is in various

Re: All about crashes

On Thu, May 26, 2016 at 1:59 AM, Eric Rescorla wrote: >> >>> Under "Ways to prevent" you suggest >>> "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, >>> using smart pointers, etc. >>> >>> This may prevent crashes in the narrow sense that it prevents

Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Hi, Here is a crash-stats search that shows all the crash reports in the past 7 days that have a "MozCrashReason" field -- which means they were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e. aggregated) by that field:

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Tue, May 31, 2016 at 5:06 PM, Chris Peterson wrote: >> >> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument >> given. These are mostly OOMs, though there are a few others in there. >> These ones should be annotated so they show up separately. > >

Re: All about crashes

On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel wrote: > > Wasn't sure how you wanted feedback. Here's some in email form. Email is great, thank you. > "Crashes are caused by defects" > > Reading this I think it implies defects in Firefox. This is not always the > case.

Re: Documentation on how to read crash reports

, so I filed bug 1275799. On Wed, May 25, 2016 at 4:06 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > Hi, > > Do we have documentation on how to read crash reports? The only thing > I have found is this page: > > https://support.mozilla.org/en-US/kb/helping-cras

Re: All about crashes

On Thu, May 26, 2016 at 1:06 PM, Lawrence Mandel wrote: > > > The aim is to make it much easier to handle intermittent test failures. > Crashes may be possible as well. > > The project is not yet well defined. Jonathan Griffin is working on this > with his team with the

Re: All about crashes

On Wed, May 25, 2016 at 3:47 PM, Eric Rahm wrote: > Thanks for putting this together! > > It would be nice to see some consolidated details on how to investigate > crashes, ie loading minidumps in Visual Studio, interpreting results, > figuring out when VS is lying to you and

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert wrote: > > Perhaps this isn't meant for me then? I looked at the query from the > first post, but it's just noise to me. If it included the file that it > crashed from, it would suddenly be very useful, since it'd then be >

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Here's an update. This one is bug 1235183: > 7 MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 % This one is covered by bug 616421 (the signature includes a combination of MOZ_CRASHes and other kinds of crashes): > 8 MOZ_CRASH(Bogus tree op)459 0.04 % Below are all

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg wrote: > You shouldn't need to annotate the file/line separately, because that is > (or at least should be!) the top of the stack. Yes. Don't get hung up on the lack of annotations. It isn't much of a problem; you can click

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew wrote: > > I took a quick look at a random one of these OOMs[1], and what strikes me > about it is that according to the crash report: > > Total Virtual Memory2147352576 > > Available Virtual Memory

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Wed, Jun 1, 2016 at 9:39 AM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > Yes. Don't get hung up on the lack of annotations. It isn't much of a > problem; you can click through easily enough. I have filed bug 1277104 > to fix the handful of instances that are show

Re: GTests are now running on test machines

> Are C++ units tests that don't use GTest still run as part of the build job? Chris told me that non-GTest C++ unit tests run in the "Cpp" job, and that one-off test programs in make check targets will continue to run as part of the build job. Nick

Re: PSA: Please stop revving UUIDs when changing XPIDL interface

Approval requests for release/beta/aurora in Bugzilla still have "[String/UUID change made/needed]" as one of the points in the checklist, too. Though maybe we need to wait for this change to reach those branches before removing that. Nick On Sat, Jan 30, 2016 at 8:52 AM, Ehsan Akhgari

Re: Does SSE2 usage still need to be conditional?

On Tue, Feb 2, 2016 at 10:55 AM, Xidorn Quan wrote: >> >> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit >> Windows. If I’m reading the data correctly, more than half. A small >> percentage of those don’t have SSE2. > > It's not surprising to

Re: Hash table iterators, and a call for help

On Fri, Jul 24, 2015 at 11:26 AM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > Given that, I went ahead and filed bugs to get rid of the ~200 > nsBaseHashtable::EnumerateRead() calls and ~140 > nsBaseHashtable::Enumerate() calls. They are all marked a

An analysis of content process memory overhead

Greetings, erahm recently wrote a nice blog post with measurements showing the overhead of enabling multiple content processes: http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ The overhead is high -- 8 content processes *doubles* our physical memory usage -- which

Re: An analysis of content process memory overhead

On Fri, Mar 18, 2016 at 2:29 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > > I seem to remember that our ChromeWorkers (SessionWorker, > PageThumbsWorker, OS.File Worker) were pretty memory-hungry, but I don't > see any workers there. Does this mean that they have negligible

Re: An analysis of content process memory overhead

On Tue, Mar 15, 2016 at 2:34 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > - > Conclusion > - > > The over

Re: Skia Content on OS X

On Wed, Mar 23, 2016 at 3:03 AM, Mason Chang wrote: > Hi David, > > The main benefit is architectural with a huge simplification of our > graphics code, with a nice side benefit of performance. As it stands today, > we have multiple different rendering paths for each platform

Re: The Object performance are 5-100 times slower than Chrome. Array is a bit slow, map is faster, uint32array are 5 times faster.

On Wed, Mar 9, 2016 at 6:40 AM, Boris Zbarsky wrote: > > That said, some of your results are a bit suspect. Indeed, microbenchmarks like these are surprisingly difficult to write well, and they often end up measuring something other than what the author intends.

Re: Report from Build Team Sprint

On Wed, Mar 9, 2016 at 7:56 AM, David Burns wrote: > > we started working on > replacing the Autoconf configure script. We are planning to replace the old > shell and m4 code with sandboxed python, which will allow us to have > improved performance (especially on Windows),

Re: An analysis of content process memory overhead

On Mon, Mar 21, 2016 at 3:50 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > - Heap overhead is significant. Reducing the page-cache size could save a > couple of MiBs. Improvements beyond that are hard. Turning on jemalloc4 > *might* help a bit, b

MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

Hi, I just landed on inbound the patches in bug 1267550, which renamed MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE. A shorter name was in order because it's an attribute that is already used widely, and should be used even more, because it catches real problems. In fact, any function that is fallible

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

On Fri, Apr 29, 2016 at 10:25 AM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > I just landed on inbound the patches in bug 1267550, which renamed > MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE. > > A shorter name was in order because it's an attribute that is already >

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

It's natural that engineers in different parts of the organisation and community will have different priorities. Let's all take a deep breath and keep the discussion calm, please. Nick On Sat, Apr 30, 2016 at 1:30 AM, wrote: > On Friday, April 29, 2016 at 2:44:25 AM UTC-5,

All about crashes

Greetings, I've written a document called "All about crashes" which I've put on the Project Uptime wiki: https://wiki.mozilla.org/Platform/Uptime#All_about_crashes It's about all the different ways we can discover, diagnose, and address crashes. It's intended to be a comprehensive, because I

Re: One Firefox repository to rule them all

For me, having the CVS history in the mozilla-central repo would be much more helpful than having all the different repositories in one. Nick On Sat, Apr 16, 2016 at 11:41 AM, smaug wrote: > On 04/15/2016 11:29 PM, Gregory Szorc wrote: >> >> On Thu, Apr 14, 2016 at 6:45 PM,

Re: PSA: Cancel your old Try pushes

On Sun, Apr 17, 2016 at 3:11 AM, L. David Baron wrote: > > We should instead use data to target advice on use of try to the > correct people, and also use that data to allow people to see where > they fit in in terms of ratios of Try resource usage to pushes, and > breaking the

Stability

On Mon, Apr 18, 2016 at 10:34 AM, Kartikaya Gupta wrote: > > My view is that if we have a lot of bugs and regressions, time spent > investigating and fixing those naturally acts as a backflow to new feature > work, which prevents the introduction of even more bugs and

Buggy AVX instruction set support detection

Hi, There is a longstanding NSS crash -- which occurs at a rate of a ~200 per week -- that appears to be caused by buggy detection of AVX instruction set support. If you know about AVX detection and want to help, please take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1263495. Thank

Re: Engineering Productivity Q1 Update

Great stuff all around! Thank you for the update. Nick On Fri, Apr 15, 2016 at 4:07 AM, Jonathan Griffin wrote: > Engineering Productivity is off to a great start in 2016; here’s what we’ve > been up to in Q1. > Build System > > Build system improvements are a major

Proposal: use nsresult& outparams in constructors to represent failure

Hi, C++ constructors can't be made fallible without using exceptions. As a result, for many classes we have a constructor and a fallible Init() method which must be called immediately after construction. Except... there is one way to make constructors fallible: use an |nsresult& aRv| outparam to

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 11:50 AM, Jim Blandy wrote: > The pattern seems reasonable enough. > > DXR says we have 2579 "init" or "Init" functions, and 9801 callers of such > functions. I used: > > function:init ext:cpp ext:h > callers:init ext:cpp ext:h There are also some

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote: >> >> Maybe you're referring to factory methods, like this: >> >> static T* T::New(); >> >> which would return null on failure. Such methods can be useful, but >> there's two problems. First, they're not applicable to

Re: Build System Project - Update from the last 2 weeks

On Thu, Apr 21, 2016 at 2:13 AM, Bobby Holley wrote: > I believe Ehsan was close to having Clang static analysis running on > Windows. Nathan Froyd has also been involved, and should be included in any discussion there. Nick ___

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote: > The general problem that > it doesn't alleviate is that failure to check the return value leaves you > with a reference/pointer to an object in an ill-defined half-constructed > state. At least for heap allocations, I'd much

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione wrote: > > If we do this, can we please use |nsresult*| rather than |nsresult&|? I prefer a reference because of the guarantee of non-nullness. But I could live with a pointer if people think it's better. Nick

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 8:41 PM, Martin Thomson wrote: > >> - I suspect that in some heap-allocated objects it will be hard to do >> the fallible parts without having an object of the relevant type. I >> don't have specific examples, just a hunch. > > I'm not aware of any way

Re: Why do we still need to include Qt widget in mozilla-central?

On Tue, Apr 12, 2016 at 2:45 PM, Masayuki Nakano wrote: > > > So, my question is, why do we still have Qt widget in mozilla-central? What the reason of keeping it in mozilla-central? The same question can be asked of widget/uikit/, which I believe is for the old,

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva wrote: > Fallible construction (even with a way to report failure) is annoying if > only because the object's destructor has to account for the possible > invalid states. I much prefer having a static creation method that will

<    1   2   3   4   5   >