Re: Removing the Chromium event loop

2016-03-30 Thread Kyle Huey 
On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:

> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>  wrote:
> > I've been unhappy with the fact that our event loop uses refcounted
> objects
> > by default. *Most* runnables are pure-C++ and really don't need to be
> > refcounted/scriptable.
>
> I've been thinking about this too.  gfx has a separate thread pool
> that was created partly because of the desire to be Gecko-free and
> partly because of the overhead that nsIRunnable has.  It would be nice
> to eliminate one of those objections.  Making this change would also
> bring down bloat from vtables and essentially-useless methods.
>

Frankly, I think this is an ex-post-facto rationalization for not liking
nsIRunnable because it's XPCOMy/not new and shiny/etc. We had this same
problem with many of the same people and the same justifications with the
mfbt RefCounted class that turned out to be a nightmare to untangle.  Turns
out things our boring old stuff had like leak checking were actually
useful!  Who could have guessed?

Unless they have actual evidence showing this matters I don't care about
their objections.

*shots_fired.jpg*

> I'm asking you to consider unifying these two things by making our event
> > loop work more like chromium and just using c++ objects without a
> refcount
> > by default? Then to post a scriptable event to an event loop you'd have
> to
> > have it own a separate scriptable object.


I'll pose to you the same question I posed bsmedberg, is this actually
worth fiddling with all the existing runnables.  It's not just scriptable
stuff that needs to be changed.

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

Re: Removing the Chromium event loop

2016-03-30 Thread Kyle Huey 
On Wed, Mar 30, 2016 at 11:34 AM, Benjamin Smedberg 
wrote:

> I support this plan!
>
> Mostly.
>
> I've been unhappy with the fact that our event loop uses refcounted
> objects by default. *Most* runnables are pure-C++ and really don't need to
> be refcounted/scriptable.
>
> I'm asking you to consider unifying these two things by making our event
> loop work more like chromium and just using c++ objects without a refcount
> by default? Then to post a scriptable event to an event loop you'd have to
> have it own a separate scriptable object.
>
> If that sounds like too much churn for your project, then please proceed
> with your original plan!
>
> --BDS
>

Well, it's obviously easier to move from new/delete to refcounted than the
reverse ... is there a reason to believe it's actually worth the cost of
de-refcountifying all the runnables in Gecko?

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

Re: Removing the Chromium event loop

2016-03-30 Thread Eric Rescorla 
On Wed, Mar 30, 2016 at 2:03 PM, Bobby Holley  wrote:

> On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla  wrote:
>
>> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:
>>
>> > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>> >  wrote:
>> > > I've been unhappy with the fact that our event loop uses refcounted
>> > objects
>> > > by default. *Most* runnables are pure-C++ and really don't need to be
>> > > refcounted/scriptable.
>> >
>> > I've been thinking about this too.  gfx has a separate thread pool
>> > that was created partly because of the desire to be Gecko-free and
>> > partly because of the overhead that nsIRunnable has.  It would be nice
>> > to eliminate one of those objections.  Making this change would also
>> > bring down bloat from vtables and essentially-useless methods.
>> >
>> > > I'm asking you to consider unifying these two things by making our
>> event
>> > > loop work more like chromium and just using c++ objects without a
>> > refcount
>> > > by default? Then to post a scriptable event to an event loop you'd
>> have
>> > to
>> > > have it own a separate scriptable object.
>> >
>> > I'd like to make this happen if Kyle doesn't.
>> >
>>
>> Do we have measurements that demonstrate that this would have a
>> substantially
>> positive performance impact? Generally, the world would be safer if we
>> always
>> used smart pointers rather than bare pointers, so it seems like we should
>> have
>> some strong evidence before pushing in the other direction.
>>
>
> I'm assuming that we would use some sort of UniquePtr-ish owning semantics
> rather than raw pointers.
>

This would certainly be acceptable. My objection is merely to raw pointers.


> That said, I think most of the overhead from having things be refcounted
> comes when AddRef and Release are virtual. We can solve that problem on its
> own by making the superclass concrete with a refcount member, and hoisting
> the reference counting onto it with statically-dispatched methods.
>

Yes, this would also be fine.

-Ekr




> bholley
>
>
>>
>> -Ekr
>>
>>
>> >
>> > -Nathan
>> > ___
>> > 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

2016-03-30 Thread Bobby Holley 
On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla  wrote:

> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:
>
> > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
> >  wrote:
> > > I've been unhappy with the fact that our event loop uses refcounted
> > objects
> > > by default. *Most* runnables are pure-C++ and really don't need to be
> > > refcounted/scriptable.
> >
> > I've been thinking about this too.  gfx has a separate thread pool
> > that was created partly because of the desire to be Gecko-free and
> > partly because of the overhead that nsIRunnable has.  It would be nice
> > to eliminate one of those objections.  Making this change would also
> > bring down bloat from vtables and essentially-useless methods.
> >
> > > I'm asking you to consider unifying these two things by making our
> event
> > > loop work more like chromium and just using c++ objects without a
> > refcount
> > > by default? Then to post a scriptable event to an event loop you'd have
> > to
> > > have it own a separate scriptable object.
> >
> > I'd like to make this happen if Kyle doesn't.
> >
>
> Do we have measurements that demonstrate that this would have a
> substantially
> positive performance impact? Generally, the world would be safer if we
> always
> used smart pointers rather than bare pointers, so it seems like we should
> have
> some strong evidence before pushing in the other direction.
>

I'm assuming that we would use some sort of UniquePtr-ish owning semantics
rather than raw pointers.

That said, I think most of the overhead from having things be refcounted
comes when AddRef and Release are virtual. We can solve that problem on its
own by making the superclass concrete with a refcount member, and hoisting
the reference counting onto it with statically-dispatched methods.

bholley


>
> -Ekr
>
>
> >
> > -Nathan
> > ___
> > 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

2016-03-30 Thread Eric Rescorla 
On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:

> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>  wrote:
> > I've been unhappy with the fact that our event loop uses refcounted
> objects
> > by default. *Most* runnables are pure-C++ and really don't need to be
> > refcounted/scriptable.
>
> I've been thinking about this too.  gfx has a separate thread pool
> that was created partly because of the desire to be Gecko-free and
> partly because of the overhead that nsIRunnable has.  It would be nice
> to eliminate one of those objections.  Making this change would also
> bring down bloat from vtables and essentially-useless methods.
>
> > I'm asking you to consider unifying these two things by making our event
> > loop work more like chromium and just using c++ objects without a
> refcount
> > by default? Then to post a scriptable event to an event loop you'd have
> to
> > have it own a separate scriptable object.
>
> I'd like to make this happen if Kyle doesn't.
>

Do we have measurements that demonstrate that this would have a
substantially
positive performance impact? Generally, the world would be safer if we
always
used smart pointers rather than bare pointers, so it seems like we should
have
some strong evidence before pushing in the other direction.

-Ekr


>
> -Nathan
> ___
> 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

2016-03-30 Thread Nathan Froyd 
On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
 wrote:
> I've been unhappy with the fact that our event loop uses refcounted objects
> by default. *Most* runnables are pure-C++ and really don't need to be
> refcounted/scriptable.

I've been thinking about this too.  gfx has a separate thread pool
that was created partly because of the desire to be Gecko-free and
partly because of the overhead that nsIRunnable has.  It would be nice
to eliminate one of those objections.  Making this change would also
bring down bloat from vtables and essentially-useless methods.

> I'm asking you to consider unifying these two things by making our event
> loop work more like chromium and just using c++ objects without a refcount
> by default? Then to post a scriptable event to an event loop you'd have to
> have it own a separate scriptable object.

I'd like to make this happen if Kyle doesn't.

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

Re: Introducing MOZ_ALWAYS_SUCCEEDS

2016-03-30 Thread Mike Hoye 

On 2016-03-29 5:19 PM, Kyle Huey wrote:

For when you are too lazy to type MOZ_ALWAYS_TRUE(NS_SUCCEEDS(foo)).

Any chance we can get this on a t-shirt?

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

Removing the Chromium event loop

2016-03-30 Thread Kyle Huey 
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.

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

Re: Announcing MozillaBuild 2.2.0 Release

2016-03-30 Thread Ryan VanderMeulen 
Darn it, I caught and fixed that when I posted the link in the tracking bug
for 2.2.0 but missed it in this post. Anyway, the installer is signed by
MoCo for this release, so you can verify that what you downloaded is legit
that way. Also, you can verify that the sha256 hash is
5662023973a90668e30d05c795db4213991a60b50052d5279ebb986fb7b9de3e. Sorry for
the confusion, I'll make sure future announcements use https.

Thanks,
Ryan

On Tue, Mar 29, 2016 at 10:57 PM, Martin Thomson  wrote:

> On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan 
> wrote:
> > I'd suggest you use https instead, it seems to work with ftp.mozilla.org
> :)
>
> Indeed.  Don't drop the scheme entirely either, since Firefox attempts
> to use FTP, which isn't available on that server.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

2016-03-30 Thread Axel Hecht 

Hi Emma,

for those of us that are addicted to data: You have about a 1000 bugs of 
data, and I'd love to hear some of the good parts, and maybe also some 
of the bad parts.


Also, you tested on three teams, and you report a success story from 
one. Could you frame that a bit? Is that within the expectations, or 
above or below?


Axel

On 29/03/16 22: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 process can help us spread the load of watching
incoming bugs and help avoid issues falling through the cracks."

During the pilot, the DOM team uncovered critical bugs quickly so that
people could be assigned to them.

The pilot groups also found that the triage process needs to be fast and
have tooling to make going through bugs fast. It’s easy to fall behind on
triage for a component, but if you stay up to date it will take no more
than 15 minutes a day.

You can find the bugs we triaged during the pilot by looking for whiteboard
tags containing ‘btpp-’.

It is also important to have consistent, shared definitions for regression
across components so triagers do not waste effort on mis-labeled bugs.
Comments?

I am posting this plan now for comment over the next week. I intend to
finalize the triage plan for implementation by Tuesday, April 5th. Feedback
and questions are welcome on the document, privately via email or IRC
(where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
Timeline

January: finish finding component responsible parties

February: pilot review of NEW bugs with four groups of components, draft
new process

Now: comment period for new process, finalize process

Q2: implement new process across all components involved in shipping Firefox
Q3: all newly triaged bugs following the new process

-- Emma Humphries, Bugmaster



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