Re: Triage Plan for Firefox Components

[Emma Humphries]

What to call these has been a long thread in the document comments, but I'm
starting to lean towards:

FIX-FOR-RELEASE
FIX-SOON
and
BACKLOG

as well as adding (see the proposed edit) a FEATURE resolution for bugs
which are feature tracking and individual features. I'd consider adding a
consistency rule requiring a User Story field for bugs in that status.


On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic 
wrote:

> This may be somewhat long winded.  I will make it in the context of Gecko
> graphics, because that’s where I have the most data and experience.  It may
> or may not apply to other components.
>
> Reviewing all the incoming bugs, in a timely matter, is very important to
> us.  Over the past few years, the graphics team fixed about half the bugs
> that came in (roughly, we fix a thousand out of the two thousand that come
> in.)  The main goal of any kind of a bug triage process is thus to choose
> the right half of the bugs to fix, and spend as little time as possible on
> the rest.
>
> With that in mind we started a much less documented and much more minimal
> process in 2015.  I don’t know that we have the data to back the “avoid
> issues falling between the cracks”, but it certainly seems that way.  One
> data point we do have - the average amount of time it took to fix the bugs
> triaged in 2015 was almost half of that for 2014 and the previous four
> years.
>
> This to illustrate that I believe in the bug triage, looking at bugs as
> they come in, and making some quick decisions how to proceed.
>
> I’m also a big believer in lightweight processes and minimal
> documentation, so there are a few comments I have on what the document
> below describes, and in general.
>
> The more states we have, the more not-so-useful conversation we’ll have
> about assigning those states.  I’m glad to see that we have a small number,
> currently named fix-now, non-urgent and wishlist (the naming is in flux and
> being argued in the document.)  I’m mentally mapping these to “blocking the
> release”, “can’t ship too many releases with this” and “I hope we
> eventually fix this”, but perhaps there is a different interpretation.
>
> I would expect to see the majority of the graphics bugs end up in the last
> group.  Why?  Since you never plan for the full capacity, as that actually
> reduces your throughput, and since we only fix half the bugs that come in,
> it stands to reason that we should not have even close to half of the bugs
> in the first two categories.  In other words, we want to be fixing some of
> the “wishlist” bugs.  And we need to be very careful about not making the
> fix-now turn into “we really should fix this”, and only allow the “team
> works on nothing else while there are fix-now bugs open”.  Otherwise, well,
> it loses its value.
>
> Step aside - my thoughts on the “How Triage Will Work in Bugzilla”
> section.  I would stick with the definition of the states and have
> dashboards that show the bug counts in different categories for different
> teams.  The current description is a bit too detailed and inflexible.  It
> suggests that we can figure out the best way to do this before we’ve even
> started doing it (the pilot program non-withstanding), and it mixes the
> mechanics with the goals.
>
> I’m going to start and keep arguing that we do not want to have an
> explicit name for that largest bucket of “wishlist” bugs, and should
> instead have it marked by the absence of a tag.  This is not about the
> heavily involved community, those that will stick around regardless of what
> we do to them, and anybody that reads this e-mail.  This is about people
> that are reporting their first bugs, that are occasionally involved, who
> are vital to our success.  If I was one of those, and I started seeing that
> most, if not all, of my bugs are marked as wishlist or deferred or
> in-copious-spare-time, I’m going to get discouraged and stop doing it.
> After all, I don’t seem to be valuably contributing, because I’m just
> telling you things you don’t care about.  Or, I could start arguing in the
> bug, that this should be higher priority, and fill up the comments with
> non-technical information.
>
> Getting close to a full page, I’ll stop now.  I’m available for live
> conversations on the topic :)
>
> —
> - Milan
>
>
>
> > On Mar 29, 2016, at 16:07 , Emma Humphries  wrote:
> >
> > tl;dr
> >
> > In Quarter Two I'm implementing the work we’ve been doing to improve
> > triage, make actionable decisions on new bugs, and prevent us from
> shipping
> > regressions in Firefox.
> >
> > Today I’m asking for feedback on the plan which is posted at:
> >
> >
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
> >
> > Allowing bugs to sit around without a decision on what we will do about
> > them sends the wrong message to Mozillans about how we treat bugs, how we
> > value their involvement, and reduces quality.
> >
> > The Firefox 

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic 
wrote:

> Or, I could start arguing in the bug, that this should be higher priority,
> and fill up the comments with non-technical information.



​This reminds me, we have filtering tools to mute abusive and unproductive
comments in bugs.

https://wiki.mozilla.org/BMO/comment_tagging

-- Emma

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

Re: Triage Plan for Firefox Components

[Emma Humphries]

I've responded to a similar comment in the google doc, but I'll repeat it
here.

Priority sounds like a great choice, but given that everyone's using the
Priority field their own way, there's enough heterogeneity in how it's used
to make it difficult.

If I was to take that approach, I'm concerned about what it would do with
historical data. We'd also have the P3, and P4 values hanging round like
vestigial limbs.

FYI, in FFx related components.

--- 460,362
P1   14,304
P2   15,971
P3   37,933
P44,204
P52,913

The bulk of bugs in FFx related components are P3.

-- Emma

On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson 
wrote:

> On 3/31/16 3:22 PM, Daniel Veditz wrote:
>
>> ​We get that now, with no marker at all. The only real difference I see
>> with a marker is that people will catch on sooner whereas now it takes a
>> while until they realize they are being ignored. They eventually get
>> discouraged​ or upset either way. Might even be better with a marker (for
>> some people) because at least they have some acknowledgement that someone
>> has looked at the bug even if they disagree about the importance. We may
>> have misunderstood, and thus mis-triaged, the bug and an explicit marker
>> might trigger the attempt to clarify sooner.
>>
>
> Anthony's Media Playback team has been using a simple and effective triage
> system without special tags. All open bugs in the Audio/Video Playback
> component are in one of four states at all times:
>
> * Priority P1 bugs should be fixed ASAP.
> * Priority P2 bugs are real bugs or features we want to fix soon.
> * Priority P5 bugs are "patches accepted" bugs.
> * Bugs without a priority are untriaged.
>
> P3 and P4 are not used. :) P5 sends a pretty clear message to people that
> we will not fix that issue any time soon. However, the P5 list is pretty
> clean because we aggressively WONTFIX bugs we truly don't want to fix
> instead of letting them linger.
>
> Bugzilla already has a lot of fields. It seems like new workflows could be
> built with a streamlined frontend UI without changing Bugzilla's database
> schema. The advantage of codifying existing workflows instead of adding new
> fields is that existing bugs will be compatible with the new system.
>
> IIRC, the Fennec team also tracked the "Someone is working on this"
> proposed in Emma's plan by assigning owners to all bugs, but developers
> would change their bug's status from NEW to ASSIGNED only when they began
> actively working on the bug.
>
> ___
> 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: Triage Plan for Firefox Components

[Chris Peterson]

On 3/31/16 3:22 PM, Daniel Veditz wrote:

​We get that now, with no marker at all. The only real difference I see
with a marker is that people will catch on sooner whereas now it takes a
while until they realize they are being ignored. They eventually get
discouraged​ or upset either way. Might even be better with a marker (for
some people) because at least they have some acknowledgement that someone
has looked at the bug even if they disagree about the importance. We may
have misunderstood, and thus mis-triaged, the bug and an explicit marker
might trigger the attempt to clarify sooner.


Anthony's Media Playback team has been using a simple and effective 
triage system without special tags. All open bugs in the Audio/Video 
Playback component are in one of four states at all times:


* Priority P1 bugs should be fixed ASAP.
* Priority P2 bugs are real bugs or features we want to fix soon.
* Priority P5 bugs are "patches accepted" bugs.
* Bugs without a priority are untriaged.

P3 and P4 are not used. :) P5 sends a pretty clear message to people 
that we will not fix that issue any time soon. However, the P5 list is 
pretty clean because we aggressively WONTFIX bugs we truly don't want to 
fix instead of letting them linger.


Bugzilla already has a lot of fields. It seems like new workflows could 
be built with a streamlined frontend UI without changing Bugzilla's 
database schema. The advantage of codifying existing workflows instead 
of adding new fields is that existing bugs will be compatible with the 
new system.


IIRC, the Fennec team also tracked the "Someone is working on this" 
proposed in Emma's plan by assigning owners to all bugs, but developers 
would change their bug's status from NEW to ASSIGNED only when they 
began actively working on the bug.

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

Re: Triage Plan for Firefox Components

[Daniel Veditz]

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic 
wrote:

> I’m going to start and keep arguing that we do not want to have an
> explicit name for that largest bucket of “wishlist” bugs, and should
> instead have it marked by the absence of a tag.


​What distinguishes a bug that has not been triaged from a bug that has
been triaged and (mentally?) put into the third bucket if there's no
explicit marker?​

This is about people that are reporting their first bugs, that are
> occasionally involved, who are vital to our success.  If I was one of
> those, and I started seeing that most, if not all, of my bugs are marked as
> wishlist or deferred or in-copious-spare-time, I’m going to get discouraged
> and stop doing it.  After all, I don’t seem to be valuably contributing,
> because I’m just telling you things you don’t care about.  Or, I could
> start arguing in the bug, that this should be higher priority, and fill up
> the comments with non-technical information.
>

​We get that now, with no marker at all. The only real difference I see
with a marker is that people will catch on sooner whereas now it takes a
while until they realize they are being ignored. They eventually get
discouraged​ or upset either way. Might even be better with a marker (for
some people) because at least they have some acknowledgement that someone
has looked at the bug even if they disagree about the importance. We may
have misunderstood, and thus mis-triaged, the bug and an explicit marker
might trigger the attempt to clarify sooner.

The people who are going to demand attention for their super important
critical blocker bug are likely to do that either way. A triage marker
might help lance the boil sooner rather than let frustration build up to
explosive levels.

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

Upcoming SSH Host Key Rotation for hg.mozilla.org

[Gregory Szorc]

This message serves as a notice that the *SSH host keys* for
hg.mozilla.org will be rotated in the next ~24 hours.

When connecting to hg.mozilla.org over SSH, your SSH client should warn
that host keys have changed and refuse to connect until
accepting/trusting the new host key. After 1st host key verification
failure:

1) `ssh-keygen -R hg.mozilla.org` to remove the old host key
2) `ssh hg.mozilla.org` and verify the fingerprint of the new key
matches one of the following:

256 SHA256:7MBAdqLe8+aSYkv+5/2LUUxd+WdgYcVSV+ZQVEKA7jA hg.mozilla.org
(ED25519)
256 SHA1:Ft++OU96cvaREKNFCJ6AiuCpGac hg.mozilla.org (ED25519)
256 MD5:96:eb:3b:78:f5:ca:19:e2:0c:a0:95:ea:04:28:7d:26 hg.mozilla.org
(ED25519)

4096 SHA256:RX2OK8A1KNWdxyu6ibIPeEGLBzc5vyQW/wd7RKjBehc hg.mozilla.org (RSA)
4096 SHA1:p2MGe4wSw8ZnQ5J9ShBk/6VA+Co hg.mozilla.org (RSA)
4096 MD5:1c:f9:cf:76:de:b8:46:d6:5a:a3:00:8d:3b:0c:53:77 hg.mozilla.org
(RSA)

Q: What host key types were changed? We dropped the DSA host key and
added a ED25519 host key. The length of the RSA key has been increased
from 2048 to 4096 bits.

Q: Does this impact connections to https://hg.mozilla.org/? No. The x509
certificate to the https:// endpoint is remaining unchanged at this time.

Q: Why is this being done? We are modernizing the server infrastructure
of hg.mozilla.org. As part of this, we're bringing the hosts in
compliance with Mozilla's SSH security guidelines
(https://wiki.mozilla.org/Security/Guidelines/OpenSSH).



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

Re: Triage Plan for Firefox Components

[Milan Sreckovic]

This may be somewhat long winded.  I will make it in the context of Gecko 
graphics, because that’s where I have the most data and experience.  It may or 
may not apply to other components.

Reviewing all the incoming bugs, in a timely matter, is very important to us.  
Over the past few years, the graphics team fixed about half the bugs that came 
in (roughly, we fix a thousand out of the two thousand that come in.)  The main 
goal of any kind of a bug triage process is thus to choose the right half of 
the bugs to fix, and spend as little time as possible on the rest.

With that in mind we started a much less documented and much more minimal 
process in 2015.  I don’t know that we have the data to back the “avoid issues 
falling between the cracks”, but it certainly seems that way.  One data point 
we do have - the average amount of time it took to fix the bugs triaged in 2015 
was almost half of that for 2014 and the previous four years.

This to illustrate that I believe in the bug triage, looking at bugs as they 
come in, and making some quick decisions how to proceed.

I’m also a big believer in lightweight processes and minimal documentation, so 
there are a few comments I have on what the document below describes, and in 
general.

The more states we have, the more not-so-useful conversation we’ll have about 
assigning those states.  I’m glad to see that we have a small number, currently 
named fix-now, non-urgent and wishlist (the naming is in flux and being argued 
in the document.)  I’m mentally mapping these to “blocking the release”, “can’t 
ship too many releases with this” and “I hope we eventually fix this”, but 
perhaps there is a different interpretation.

I would expect to see the majority of the graphics bugs end up in the last 
group.  Why?  Since you never plan for the full capacity, as that actually 
reduces your throughput, and since we only fix half the bugs that come in, it 
stands to reason that we should not have even close to half of the bugs in the 
first two categories.  In other words, we want to be fixing some of the 
“wishlist” bugs.  And we need to be very careful about not making the fix-now 
turn into “we really should fix this”, and only allow the “team works on 
nothing else while there are fix-now bugs open”.  Otherwise, well, it loses its 
value.

Step aside - my thoughts on the “How Triage Will Work in Bugzilla” section.  I 
would stick with the definition of the states and have dashboards that show the 
bug counts in different categories for different teams.  The current 
description is a bit too detailed and inflexible.  It suggests that we can 
figure out the best way to do this before we’ve even started doing it (the 
pilot program non-withstanding), and it mixes the mechanics with the goals.

I’m going to start and keep arguing that we do not want to have an explicit 
name for that largest bucket of “wishlist” bugs, and should instead have it 
marked by the absence of a tag.  This is not about the heavily involved 
community, those that will stick around regardless of what we do to them, and 
anybody that reads this e-mail.  This is about people that are reporting their 
first bugs, that are occasionally involved, who are vital to our success.  If I 
was one of those, and I started seeing that most, if not all, of my bugs are 
marked as wishlist or deferred or in-copious-spare-time, I’m going to get 
discouraged and stop doing it.  After all, I don’t seem to be valuably 
contributing, because I’m just telling you things you don’t care about.  Or, I 
could start arguing in the bug, that this should be higher priority, and fill 
up the comments with non-technical information.

Getting close to a full page, I’ll stop now.  I’m available for live 
conversations on the topic :)

—
- Milan



> On Mar 29, 2016, at 16:07 , Emma Humphries  wrote:
> 
> tl;dr
> 
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
> 
> Today I’m asking for feedback on the plan which is posted at:
> 
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
> 
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
> 
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
> 
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
> 
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage 

Re: A lot of problems with Firefox Sync...

[Gijs Kruitbosch]

On 24/03/2016 00:08, Tobias B. Besemer wrote:

But what is this:
user_pref("extensions.checkCompatibility.37.0a", true);
user_pref("extensions.checkCompatibility.nightly", true);


Preferences relating to how/whether the add-on manager checks for 
compatibility with a particular release. Not sure why they'd be a 
non-default value. Could be another add-on, could be that you set these. 
See also: http://kb.mozillazine.org/Extensions.checkCompatibility .


~ Gijs

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

Re: Removing the Chromium event loop

[Kyle Huey]

On Thu, Mar 31, 2016 at 3:19 AM, Honza Bambas  wrote:

> On 3/30/2016 20:21, Kyle Huey wrote:
>
>> In the department-of-paying-down-technical-debt, I'm planning to remove
>> much of the Chromium event loop over the next few months. You can follow
>> along in bug 1260828.
>>
>> The rough outline:
>>
>> Step 1: Replace Task with nsIRunnable, without changing any other
>> semantics.  This will happen in late April, after Gecko 48 branches.
>> Step 2: Either remove PostDelayedTask, or reimplement its semantics in
>> nsThread.
>> Step 3: Remove Chromium event loops using TYPE_DEFAULT and
>> TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
>> TYPE_DEFAULT runs a Chromium Tasks only event loop, and
>> TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
>> normal XPCOM event loop.
>> Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
>> main threads of parent and content processes respectively, and aren't much
>> harder than step 3.
>>
>> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
>> involve varying levels of platform specific event loop or API integration
>> that will probably be more difficult to untangle. They also won't block my
>> long-term desire to build a scheduler for Gecko, so are lower priority.
>>
>> If you have objections, speak now or forever hold your peace.
>>
>
> Few questions:
>
> - how will this impact the IPC pumping that is based on Tasks?
>

It will be changed to not use Tasks.


> - do you have more details/ideas/bugs about your scheduler?  I may have
> similar thoughts, like adding priorities to (not only) main thread events.
> Backtrack (bug 1148204) should give hints (at least) how such a scheduler
> should behave and check if does what we want.
>

At a very high level, there will be an event queue per global and we'll
prioritize the queues for things in the foreground.  There are also
opportunities to prioritize within a given queue, according to the HTML
spec, but it's not clear how much of that is web compatible.

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

Re: Removing the Chromium event loop

[Boris Zbarsky]

On 3/31/16 8:08 AM, Gabriele Svelto wrote:

On this topic, did anyone experiment with trying to lighten the
synchronization burden when handling nsEventQueues?


This has come up in profiles recently too.  For example 
https://bugzilla.mozilla.org/show_bug.cgi?id=1254240#c6 shows us 
acquiring and releasing multiple locks when posting a runnable to either 
a web worker or main thread...


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

Re: Triage Plan for Firefox Components

[Lawrence Mandel]

Softvision also makes use of the feature keyword as one way to identify new
feature work to test in upcoming releases.

Lawrence

On Thu, Mar 31, 2016 at 10:49 AM, Milan Sreckovic 
wrote:

> We do have a feature keyword today.  While it may be most used for the
> documentation purposes, the feedback graphics team got when we started
> using it to tag feature requests was positive.  As in, it’s OK to use for
> that.
> —
> - Milan
>
>
>
> > On Mar 29, 2016, at 22:32 , Emma Humphries  wrote:
> >
> > On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla  wrote:
> >
> >> On a more substantive, less procedural note, this seems to be designed
> for
> >> a particular workflow in which there is an assumption that bugs are for
> >> immediate processing. However, in may cases we use bugs as placeholders
> or
> >> assemble big dependency trees of all the bugs that are needed to do a
> large
> >> complex feature. From this perspective, a three-tier system of "urgent",
> >> "non-urgent", and "wishlist" is either a regression from more
> fine-grained
> >> systems such as dependency trees/priorities or is redundant with them.
> This
> >> is especially true for long-running efforts. In other words, this may
> be a
> >> useful change for some components while not being useful for others. For
> >> the specific case of NSS (where I currently do a lot of my work) this
> >> doesn't seem like it would be a helpful change.
> >
> >
> > ​This is where it would be nice to have a way of saying, feature vs. bug
> as
> > part of the triage process, even it that's not a clean separation to
> make,
> > because that could get long running feature work out of the triage
> process,
> > but I don't have an immediate answer for this. It may be that we change
> the
> > scope of components this applies to.
> >
> > I'll follow up with Doug Turner to see if changing the scope of this for
> > platform related bugs is warranted.
> >
> > ​
> > --
> > ​ Emma​
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Chromium event loop

[Gian-Carlo Pascutto]

On 31-03-16 15:17, Jim Mathies wrote:
> On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
>> The other types (TYPE_UI, TYPE_IO, and
>> TYPE_MOZILLA_NONMAINUITHREAD) involve varying levels of platform
>> specific event loop or API integration that will probably be more
>> difficult to untangle. They also won't block my long-term desire to
>> build a scheduler for Gecko, so are lower priority.
> 
> We might be able to convert TYPE_MOZILLA_NONMAINUITHREAD to a
> TYPE_MOZILLA_NONMAINTHREAD now. This was added for media code which
> was (is still?) interacting with native windows on the desktop,
> chatting with local devices, and other related native media activity.
> It might be overkill now. An audit of what we ended up using here
> would tell. The loop isn't troublesome in any way but might be a pain
> to convert over to whatever new system you plan to  implement.

The bug that introduced the usage is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1060738

We still use this code for WebRTC, although it's in CamerasParent now. I
think MediaManager still uses NONMAINUITHREAD as well but it probably
doesn't need to anymore, because the camera access got moved outside its
thread.

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

Re: Removing the Chromium event loop

[Nathan Froyd]

On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto  wrote:
> On this topic, did anyone experiment with trying to lighten the
> synchronization burden when handling nsEventQueues? Both nsThread and
> nsThreadPool acquire a mutex each time we need to get the next runnable;
> we could pull out all pending runnables every time we acquire the lock
> (up to a predefined maximum) to amortize the synchronization cost. In my
> measurements mutex-handling was also quite expensive on low-end ARM
> cores, not so much on x86 as long as the mutex was not contended.

There was some optimization work done in bug 1195767 and bug 1202497
to reduce the amount of locking we do for both nsThreadPool and
nsThread, respectively, and to use signaling on internal condition
variables rather than broadcast.  I know the changes were significant
in the case of nsThreadPool on some platforms; in the nsThread case we
are obviously doing less work, but I didn't try to measure the
savings.  I don't think we've experimented with trying to pull out
multiple events per lock acquisition (which sounds pretty tricky to do
such that you're actually saving work).

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

Re: Removing the Chromium event loop

[Jim Mathies]

On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
> involve varying levels of platform specific event loop or API integration
> that will probably be more difficult to untangle. They also won't block my
> long-term desire to build a scheduler for Gecko, so are lower priority.

We might be able to convert TYPE_MOZILLA_NONMAINUITHREAD to a 
TYPE_MOZILLA_NONMAINTHREAD now. This was added for media code which was (is 
still?) interacting with native windows on the desktop, chatting with local 
devices, and other related native media activity. It might be overkill now. An 
audit of what we ended up using here would tell. The loop isn't troublesome in 
any way but might be a pain to convert over to whatever new system you plan to  
implement.

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

Re: Removing the Chromium event loop

[Gabriele Svelto]

On 31/03/2016 07:42, Kyle Huey wrote:
> I'll pose to you the same question I posed bsmedberg, is this actually
> worth fiddling with all the existing runnables.

I did some testing around a couple of years ago and the answer is the
same as usual: it depends. On modern x86 machines I doubt one would be
able to measure the difference; sure it's there, but it's small enough
that it's generally not worth the fuss.

On entry-level ARM stuff (Cortex A5, A7, etc...) it's definitely there,
but mostly because using nsIRunnable requires atomics for ref-counting
which are very expensive on those cores. So there's definitely a cost
over stuffing a raw (function) pointer into an array and calling it later.

So it comes down to a cost/benefit tradeoff. On the one hand it would be
nice to have a lighter alternative to nsIRunnable provided it doesn't
require massive changes in the code, on the other hand its impact would
be limited on the vast majority of our users.

On this topic, did anyone experiment with trying to lighten the
synchronization burden when handling nsEventQueues? Both nsThread and
nsThreadPool acquire a mutex each time we need to get the next runnable;
we could pull out all pending runnables every time we acquire the lock
(up to a predefined maximum) to amortize the synchronization cost. In my
measurements mutex-handling was also quite expensive on low-end ARM
cores, not so much on x86 as long as the mutex was not contended.

 Gabriele



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