Re: IPCStream landed in mozilla-central

[Ting-Yu Chou]

On Fri, May 20, 2016 at 2:19 AM, Ben Kelly  wrote:

> On Thu, May 19, 2016 at 1:41 PM, Andrew McCreight 
> wrote:
>
> > On Thu, May 19, 2016 at 8:04 AM, Ben Kelly  wrote:
> >
> > > 3) Supports async pipe streams using a new PSendStream actor from
> > > *child-to-parent*.  I have plans to add support for parent-to-child,
> but
> > I
> > > don't have a consumer yet and we need to figure out some issues with
> > > PBackground targeting worker threads.
> > >
> >
> > One place that this would be very useful would be for networking. Right
> > now, the various networking protocols send data to the child by calling
> > NS_ReadInputStreamToString(), then copying the string into an IPC
> message,
> > which is bad because it requires a lot of contiguous memory addresses,
> and
> > also has a fair bit of bloat from all of the copies (bug 1110596, bug
> > 1263028).
> >
>
> That would be a good thing to try.  I wonder how many consumers assume
> nsIChannel::OnDataAvailable() provides a fixed length stream, though.
>

The copying we want to avoid in bug 1110596 is from a stream to a nsCString
buffer, which to let a stream write to the IPC Pickle buffer directly.

But I checked SendStreamChildImpl::DoRead() [1], it still reads to a
nsCString buffer at first. The good thing is it sends the stream's data in
chunks of 32k at maximum, which can avoid the bloat.

[1]
https://dxr.mozilla.org/mozilla-central/rev/c4449eab07d39e20ea315603f1b1863eeed7dcfe/ipc/glue/SendStreamChild.cpp#276-282

Ting


> Here is the bug to track parent-to-child pipe streaming:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1274343
>
> Thanks.
>
> Ben
> ___
> 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: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Karl Tomlinson]

Could the lack of failure emails be specific to taskcluster jobs?

https://treeherder.mozilla.org/#/jobs?repo=try=a8c6ab15dd8f
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Gregory Arndt]

Retriggering was unintentionally broke earlier this week. We will be
making it a priority to fix this.

I'm sorry that it has caused a great deal of frustration and soon
we'll have it back!

-Greg

> On May 19, 2016, at 7:21 PM, J. Ryan Stinnett  wrote:
>
>> On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan  wrote:
>> 2. I cannot retrigger any TC task.
>>
>> This is pretty annoying when I was debugging intermittent issues. Hopefully
>> they could get fix before we migrate all Linux builds to TaskCluster,
>> otherwise we will lose the ability to debug certain kinds of bugs with
>> Linux builds.
>
> Other people have also mentioned that they can't retrigger these TC
> tasks, so this part sounds accurate. Bug 1274176 was filed recently
> about this. I hope it will be prioritized, I agree it's frustrating
> when working on intermittents.
>
> - Ryan
> ___
> tools-taskcluster mailing list
> tools-taskclus...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools-taskcluster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Mike Hommey]

On Thu, May 19, 2016 at 07:20:30PM -0500, J. Ryan Stinnett wrote:
> On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan  wrote:
> > 2. I cannot retrigger any TC task.
> >
> > This is pretty annoying when I was debugging intermittent issues. Hopefully
> > they could get fix before we migrate all Linux builds to TaskCluster,
> > otherwise we will lose the ability to debug certain kinds of bugs with
> > Linux builds.
> 
> Other people have also mentioned that they can't retrigger these TC
> tasks, so this part sounds accurate. Bug 1274176 was filed recently
> about this. I hope it will be prioritized, I agree it's frustrating
> when working on intermittents.

It's also not possible to *trigger* new TC jobs on treeherder ; like,
pushing with no try syntax and filling what you want with "Add new
jobs". Or using "Add new job" after realizing you forgot a job in your
try syntax.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Xidorn Quan]

On Fri, May 20, 2016 at 10:20 AM, J. Ryan Stinnett  wrote:

> On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan 
> wrote:
> > 2. I cannot retrigger any TC task.
> >
> > This is pretty annoying when I was debugging intermittent issues.
> Hopefully
> > they could get fix before we migrate all Linux builds to TaskCluster,
> > otherwise we will lose the ability to debug certain kinds of bugs with
> > Linux builds.
>
> Other people have also mentioned that they can't retrigger these TC
> tasks, so this part sounds accurate. Bug 1274176 was filed recently
> about this. I hope it will be prioritized, I agree it's frustrating
> when working on intermittents.


Oh, and forgot to mention, TC jobs are not triggerable via the "Add new
Jobs" menu, either.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[J. Ryan Stinnett]

On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan  wrote:
> 2. I cannot retrigger any TC task.
>
> This is pretty annoying when I was debugging intermittent issues. Hopefully
> they could get fix before we migrate all Linux builds to TaskCluster,
> otherwise we will lose the ability to debug certain kinds of bugs with
> Linux builds.

Other people have also mentioned that they can't retrigger these TC
tasks, so this part sounds accurate. Bug 1274176 was filed recently
about this. I hope it will be prioritized, I agree it's frustrating
when working on intermittents.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Xidorn Quan]

On Fri, May 20, 2016 at 8:16 AM, Selena Deckelmann 
wrote:

> Closing out this thread - we made Linux 64 Debug builds Tier 1 mid-April,
> and last week we turned off the related buildbot jobs.
>
> All Linux 64 Debug builds and tests now happen exclusively in TaskCluster!
>
> Thank you all the teams and individuals that contributed to getting this
> done! We NI'd quite a few people throughout Platform on test and build
> system errors, and we appreciated all of the attention and help.
>
> *Project update:*
> We're now working steadily toward getting all remaining Linux builds and
> tests into TaskCluster and to Tier 2, and Windows builds to Tier 2 in
> TaskCluster by the end of the quarter. We're also alpha testing OS X tests
> on data center hardware using TC workers.
>
> We've also started supporting a few smaller projects, in addition to a few
> groups that have migrated their builds and tests to TaskCluster. Those
> projects are still at an experimental level of support, but we're open to
> discussing support with any teams interested in building with us. We're
> primarily able to support pushes to try and Github users "out of the box."
>
> We've got a dashboard to track progress under development that we'll share
> with everyone at London.
>
> Meanwhile, the project team meets weekly on Thursdays and keeps an updated
> Trello board here: https://trello.com/b/asIJ2pGC/taskcluster-migration
>
> Questions? Please get in touch! irc:selenamarie or email or schedule a
> meeting.
>

BTW, starting yesterday, there was a "TaskClusterRobot" comment on my m-i
push on GitHub with message "TaskCluster: @upsuper does not have permission
to trigger tasks." [1][2]

I have no idea what it is talking...

[1]
https://github.com/mozilla/gecko-dev/commit/744f2efb4ac3f8502ae2f26a22831d23b7975657#commitcomment-17533456
[2]
https://github.com/mozilla/gecko-dev/commit/d076cfb56121cb6190a7aedafdd5c3e756d9d819#commitcomment-17537620

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Xidorn Quan]

On Fri, May 20, 2016 at 9:36 AM, Gregory Szorc  wrote:

> On Thu, May 19, 2016 at 4:24 PM, Xidorn Quan 
> wrote:
>
>> On Fri, May 20, 2016 at 8:16 AM, Selena Deckelmann 
>> wrote:
>>
>> > Closing out this thread - we made Linux 64 Debug builds Tier 1
>> mid-April,
>> > and last week we turned off the related buildbot jobs.
>> >
>> > All Linux 64 Debug builds and tests now happen exclusively in
>> TaskCluster!
>> >
>> > Thank you all the teams and individuals that contributed to getting this
>> > done! We NI'd quite a few people throughout Platform on test and build
>> > system errors, and we appreciated all of the attention and help.
>> >
>> > *Project update:*
>> > We're now working steadily toward getting all remaining Linux builds and
>> > tests into TaskCluster and to Tier 2, and Windows builds to Tier 2 in
>> > TaskCluster by the end of the quarter. We're also alpha testing OS X
>> tests
>> > on data center hardware using TC workers.
>> >
>> > We've also started supporting a few smaller projects, in addition to a
>> few
>> > groups that have migrated their builds and tests to TaskCluster. Those
>> > projects are still at an experimental level of support, but we're open
>> to
>> > discussing support with any teams interested in building with us. We're
>> > primarily able to support pushes to try and Github users "out of the
>> box."
>> >
>> > We've got a dashboard to track progress under development that we'll
>> share
>> > with everyone at London.
>> >
>> > Meanwhile, the project team meets weekly on Thursdays and keeps an
>> updated
>> > Trello board here: https://trello.com/b/asIJ2pGC/taskcluster-migration
>> >
>> > Questions? Please get in touch! irc:selenamarie or email or schedule a
>> > meeting.
>>
>>
>> There are several issues with TC:
>> 1. Try syntax cannot control TC tasks,
>> 2. I cannot retrigger any TC task.
>>
>
> I've seen the TC code for parsing Try syntax and deriving scheduling from
> it. And I've retriggered TC tasks from Treeherder. I reckon you are hitting
> a bug or your claim is outdated.
>

I think I saw those issues several days ago... Actually 3 days ago. So
there is an example:
https://treeherder.mozilla.org/#/jobs?repo=try=e41281966765

You can see that tc-M and tc-M-e10s on Linux x64 opt and debug has far more
tests than others.

I didn't try retriggering the tc tasks here, though, because I could not
find the test I needed to retrigger. You can see that all buildbot jobs I
retriggered there had test_pointerlock-api.html run, but I could not find
that test in log of any of the tc jobs. I have no idea why. This is another
issue I forgot to mention.

For retriggering, I just found it yesterday with this try push:
https://treeherder.mozilla.org/#/jobs?repo=try=05f8b545cb23

I was debugging an failure on tc-M(c3), but I could not retrigger that task
at all in this push.

So I don't think the claim is outdated...

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Robert Strong]

On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg:
> > We have considered this, but in the grand rollout plans for 64-bit
> Firefox
> > it's low on the list. We're still dealing with Flash
> sandboxing/functional
> > regressions as a blocker for wider rollout, and the next step is probably
> > to progressively roll out win64 to new users before we consider anything
> > for existing users.
> >
> > This will be much easier now that we have widevine and are dropping
> > npapi/silverlight, but addon compat is also a concern and we wanted to
> > partly wait for webextensions before pushing more on this.
> >
> > --BDS
>
> Sounds like a plan for me!
> Maybe there can be a ship of a installer that include 32bit & 64bit?
> Or at least have one web-installer for both versions?
> Also giving the user the change to make a easy upgrade from 32bit to 64bit
> with the offline-installer would be nice and a good test-drive for a future
> auto-update...
>
The installer does not equal auto-update. Two separate things entirely.
Download size for a combined installer is not something we want to do to
people on slow network connection but the auto selection via the stub
installer is planned though no completion date yet due to other work having
priority.



>
>
> > On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarek 
> wrote:
> >
> > > Hello,
> > >
> > > Given all the discussion around SSE[2] lately, I was curious as to
> > > whether we had made any plans to update Windows users that are running
> > > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
> > > builds. The 64-bit Windows builds do use SSE2, since that's a baseline
> > > requirement for x86-64 processors, and the overall performance should
> > > generally be better (modulo memory usage, I'm not sure if we have an
> > > exact comparison). Additionally 64-bit builds are much less likely to
> > > encounter OOM crashes due to address space fragmentation since they
> have
> > > a very large address space compared to the maximum 4GB available to the
> > > 32-bit builds.
> > >
> > > It does seem like we'd need some minimal checking here, obviously first
> > > for whether the user is running 64-bit Windows, but also possibly
> > > whether they use 32-bit plugins (until such time as we unsupport
> NPAPI).
> > > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not
> have
> > > the equivalent of Universal binaries like we do on OS X).
> > >
> > > -Ted
> > > ___
> > > 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: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Andrew McCreight]

On Thu, May 19, 2016 at 4:09 PM, Matthew N.  wrote:

> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
>

Another good thing about it is that set*Pref isn't actually synchronous in
the e10s content process, so you can end up with the pref not being set at
the right time. (IIRC the set pref sends a message to the parent telling it
to update the pref, but then continues running before the parent sends a
message back down to the child to actually set the child process pref.)

Andrew


> There are various places in the tree which wrote their own Promise
> wrappers for pushPrefEnv so feel free to file follow-up bugs blocking bug
> 1197310 to remove them.
>
> Cheers,
> Matthew N. (:MattN)
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1197310
>
> P.S. For those of you who didn't hear (since there was no announcement),
> you can use add_task in mochitest-plain and mochitest-chrome thanks to bug
> 1187701 if you load …/tests/SimpleTest/SpawnTask.js.
> ___
> 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: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Gregory Szorc]

On Thu, May 19, 2016 at 4:24 PM, Xidorn Quan  wrote:

> On Fri, May 20, 2016 at 8:16 AM, Selena Deckelmann 
> wrote:
>
> > Closing out this thread - we made Linux 64 Debug builds Tier 1 mid-April,
> > and last week we turned off the related buildbot jobs.
> >
> > All Linux 64 Debug builds and tests now happen exclusively in
> TaskCluster!
> >
> > Thank you all the teams and individuals that contributed to getting this
> > done! We NI'd quite a few people throughout Platform on test and build
> > system errors, and we appreciated all of the attention and help.
> >
> > *Project update:*
> > We're now working steadily toward getting all remaining Linux builds and
> > tests into TaskCluster and to Tier 2, and Windows builds to Tier 2 in
> > TaskCluster by the end of the quarter. We're also alpha testing OS X
> tests
> > on data center hardware using TC workers.
> >
> > We've also started supporting a few smaller projects, in addition to a
> few
> > groups that have migrated their builds and tests to TaskCluster. Those
> > projects are still at an experimental level of support, but we're open to
> > discussing support with any teams interested in building with us. We're
> > primarily able to support pushes to try and Github users "out of the
> box."
> >
> > We've got a dashboard to track progress under development that we'll
> share
> > with everyone at London.
> >
> > Meanwhile, the project team meets weekly on Thursdays and keeps an
> updated
> > Trello board here: https://trello.com/b/asIJ2pGC/taskcluster-migration
> >
> > Questions? Please get in touch! irc:selenamarie or email or schedule a
> > meeting.
>
>
> There are several issues with TC:
> 1. Try syntax cannot control TC tasks,
> 2. I cannot retrigger any TC task.
>

I've seen the TC code for parsing Try syntax and deriving scheduling from
it. And I've retriggered TC tasks from Treeherder. I reckon you are hitting
a bug or your claim is outdated.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Xidorn Quan]

On Fri, May 20, 2016 at 8:16 AM, Selena Deckelmann 
wrote:

> Closing out this thread - we made Linux 64 Debug builds Tier 1 mid-April,
> and last week we turned off the related buildbot jobs.
>
> All Linux 64 Debug builds and tests now happen exclusively in TaskCluster!
>
> Thank you all the teams and individuals that contributed to getting this
> done! We NI'd quite a few people throughout Platform on test and build
> system errors, and we appreciated all of the attention and help.
>
> *Project update:*
> We're now working steadily toward getting all remaining Linux builds and
> tests into TaskCluster and to Tier 2, and Windows builds to Tier 2 in
> TaskCluster by the end of the quarter. We're also alpha testing OS X tests
> on data center hardware using TC workers.
>
> We've also started supporting a few smaller projects, in addition to a few
> groups that have migrated their builds and tests to TaskCluster. Those
> projects are still at an experimental level of support, but we're open to
> discussing support with any teams interested in building with us. We're
> primarily able to support pushes to try and Github users "out of the box."
>
> We've got a dashboard to track progress under development that we'll share
> with everyone at London.
>
> Meanwhile, the project team meets weekly on Thursdays and keeps an updated
> Trello board here: https://trello.com/b/asIJ2pGC/taskcluster-migration
>
> Questions? Please get in touch! irc:selenamarie or email or schedule a
> meeting.


There are several issues with TC:
1. Try syntax cannot control TC tasks,
2. I cannot retrigger any TC task.

This is pretty annoying when I was debugging intermittent issues. Hopefully
they could get fix before we migrate all Linux builds to TaskCluster,
otherwise we will lose the ability to debug certain kinds of bugs with
Linux builds.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Selena Deckelmann]

Closing out this thread - we made Linux 64 Debug builds Tier 1 mid-April,
and last week we turned off the related buildbot jobs.

All Linux 64 Debug builds and tests now happen exclusively in TaskCluster!

Thank you all the teams and individuals that contributed to getting this
done! We NI'd quite a few people throughout Platform on test and build
system errors, and we appreciated all of the attention and help.

*Project update:*
We're now working steadily toward getting all remaining Linux builds and
tests into TaskCluster and to Tier 2, and Windows builds to Tier 2 in
TaskCluster by the end of the quarter. We're also alpha testing OS X tests
on data center hardware using TC workers.

We've also started supporting a few smaller projects, in addition to a few
groups that have migrated their builds and tests to TaskCluster. Those
projects are still at an experimental level of support, but we're open to
discussing support with any teams interested in building with us. We're
primarily able to support pushes to try and Github users "out of the box."

We've got a dashboard to track progress under development that we'll share
with everyone at London.

Meanwhile, the project team meets weekly on Thursdays and keeps an updated
Trello board here: https://trello.com/b/asIJ2pGC/taskcluster-migration

Questions? Please get in touch! irc:selenamarie or email or schedule a
meeting.

-selena

On Fri, Mar 18, 2016 at 3:05 PM Selena Deckelmann 
wrote:

> The two outstanding bugs are closed!
>
> We have one bug remaining that we are tracking related to metrics. I've
> consulted the owners of that issue and they've agreed that it is ok if that
> work lands shortly after we switch to Tier 1 for Linux Debug builds.
>
> We're now planning to switch TC builds to Tier 1 on March 23. Next email
> should be notification that the switch is complete.
>
> Thank you for your patience!
>
> -selena
>
>
>
>
> On Mon, Mar 14, 2016 at 2:41 PM Selena Deckelmann 
> wrote:
>
>> We've got two outstanding bugs (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1231320 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1174263), and so are
>> postponing this for at least a week. I will give an update this Friday if
>> we're able to set a date for the switch over.
>>
>> Sorry for the noise!
>>
>> -selena
>>
>>
>> On Tue, Mar 8, 2016 at 2:06 PM Selena Deckelmann 
>> wrote:
>>
>>> The time has come! We are planning to switch to Tier-1 on Treeherder for
>>> TaskCluster Linux 64 Debug build jobs on March 14. At the same time, we
>>> will hide the Buildbot build jobs, but continue running them.
>>>
>>> On March 21, we plan to switch the Linux 64 Debug tests to Tier-1 and
>>> hide the related Buildbot test jobs.
>>>
>>> After about 30 days, we plan to disable and remove all Buildbot jobs
>>> related to Linux Debug.
>>>
>>>
>>>
>>> Background:
>>>
>>> We've been running Linux 64 Debug builds and tests using TaskCluster
>>> side-by-side with Buildbot jobs since February 18th. Some of the project
>>> work that was done to green up the tests is documented here:
>>> https://public.etherpad-mozilla.org/p/buildbot-to-taskcluster-migration
>>>
>>> The new tests are running in Docker-ized environments, and the Docker
>>> images we use are defined in-tree and publicly accessible.
>>>
>>> This work was the culmination of many months of effort, with Joel Maher,
>>> Dustin Mitchell and Armen Zambrano primarily focused on test migration this
>>> quarter. Thank you to everyone who responded to NEEDINFOs, emails and pings
>>> on IRC to help with untangling busted test runs.
>>>
>>> On performance, we're taking a 14% hit across all the new test jobs vs.
>>> the old jobs in Buildbot. We ran two large-scale tests to help determine
>>> where slowness might still be lurking, and were able to find and fix many
>>> issues. There are a handful of jobs remaining that seem significantly
>>> slower, while others are significantly faster.  We decided that it was more
>>> important to deprecate the old jobs and start exclusively maintaining the
>>> new jobs now, rather than wait to resolve the remaining performance issues.
>>> Over time we hope to address issues with the owners of the affected test
>>> suites.
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Matthew N.]

Hello,

One of the reasons developers have been avoiding pushPrefEnv compared to 
the synchronous set*Pref (with a registerCleanupFunction) is because 
pushPrefEnv required using a callback function to wait for the 
preference change before moving on in the test file. This can make the 
test flow more complicated (especially when using add_task) and 
therefore harder to follow.


Bug 1197310[1] made pushPrefEnv/popPrefEnv/flushPrefEnv return a promise 
which resolves when the callbacks would have been called so now you can 
simply write test code like so:


add_task(function* setup() {
  yield SpecialPowers.pushPrefEnv({"set": [["signon.debug", true]]});
  …
})

As a reminder, the nice thing about pushPrefEnv is that the pref changes 
are reverted at the end of the test file which avoids them leaking into 
other tests unintentionally.


There are various places in the tree which wrote their own Promise 
wrappers for pushPrefEnv so feel free to file follow-up bugs blocking 
bug 1197310 to remove them.


Cheers,
Matthew N. (:MattN)

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

P.S. For those of you who didn't hear (since there was no announcement), 
you can use add_task in mochitest-plain and mochitest-chrome thanks to 
bug 1187701 if you load …/tests/SimpleTest/SpawnTask.js.

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg:
> We have considered this, but in the grand rollout plans for 64-bit Firefox
> it's low on the list. We're still dealing with Flash sandboxing/functional
> regressions as a blocker for wider rollout, and the next step is probably
> to progressively roll out win64 to new users before we consider anything
> for existing users.
> 
> This will be much easier now that we have widevine and are dropping
> npapi/silverlight, but addon compat is also a concern and we wanted to
> partly wait for webextensions before pushing more on this.
> 
> --BDS

Sounds like a plan for me!
Maybe there can be a ship of a installer that include 32bit & 64bit?
Or at least have one web-installer for both versions?
Also giving the user the change to make a easy upgrade from 32bit to 64bit with 
the offline-installer would be nice and a good test-drive for a future 
auto-update...


> On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarek  wrote:
> 
> > Hello,
> >
> > Given all the discussion around SSE[2] lately, I was curious as to
> > whether we had made any plans to update Windows users that are running
> > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
> > builds. The 64-bit Windows builds do use SSE2, since that's a baseline
> > requirement for x86-64 processors, and the overall performance should
> > generally be better (modulo memory usage, I'm not sure if we have an
> > exact comparison). Additionally 64-bit builds are much less likely to
> > encounter OOM crashes due to address space fragmentation since they have
> > a very large address space compared to the maximum 4GB available to the
> > 32-bit builds.
> >
> > It does seem like we'd need some minimal checking here, obviously first
> > for whether the user is running 64-bit Windows, but also possibly
> > whether they use 32-bit plugins (until such time as we unsupport NPAPI).
> > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
> > the equivalent of Universal binaries like we do on OS X).
> >
> > -Ted
> > ___
> > 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: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Freitag, 13. Mai 2016 14:35:52 UTC+2 schrieb Ben Hearsum:
> On 2016-05-12 06:44 PM, khagar...@gmail.com wrote:
> > On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote:
> >> Lawrence Mandel writes:
> >>
> >>> Do we need this criteria?
> >>>
> >>> RAM - Does it hurt to move an instance that has <4GB?
> >>
> >> Yes.  OOM will be more common with 64-bit builds on systems with
> >> less RAM because 64-bit builds use more memory.
> >
> > Quite the opposite actually. The overhead is negligible, but the stability 
> > improvement is tremendous. After switching to 64-bit I haven't crashed even 
> > once for several months, whereas on 32-bit I crashed several times a week.
> >
> 
> How much RAM do you have? 64-bit builds should use more memory than 
> 32-bit builds under the same circumstances. As others in this thread 
> have noted, this can lead to easier OOM crashes and slowness to due 
> additional swapping. If you have a bunch of RAM these downsides go away.

After there get a lot of mem problems fixed in FF over the last months, FF use 
in general less mem then before!
IMHO try to fix more mem-probs/-leaks should bring in general more and then you 
can forget get overhead.
(* My experiences with monitoring the FF mem over the last ~2.5years.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Freitag, 13. Mai 2016 10:34:59 UTC+2 schrieb bo...@mozilla.com:
> On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson  wrote:
> > Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit 
> > Firefox. Streaming video services will likely move their Firefox users 
> > from Silverlight to Widevine this year, so Silverlight usage will 
> > decline by EOY.
> 
> As Flash Player doesn't provide Protected Mode for 64-bit, we've enabled our 
> own sandbox.
> Unfortunately this causes some regressions as the Flash DLL was never 
> designed to be sandboxed when run in process like this. We'd like to 
> strengthen the policy, but that breaks too many things.
> 
> So, we'd have to think carefully before deciding who we could move.
>  
> > On 5/12/16 1:10 PM, Ryan VanderMeulen wrote:
> > > Flash installs the 32-bit and 64-bit plugin versions side by side
> > > already (in System32 and SysWOW64, respectively), so I don't think
> > > that's an issue here.
> 
> Confusingly the 64-bit version lives in System32 and the 32-bit version in 
> SysWOW64.
> This is Microsoft's confusion not Adobe's.
> SysWOW64 generally contains files used for running 32-bit binaries on 64-bit 
> Windows (WOW64 is Windows [32-bit] On Windows 64[-bit])
> System32 is just a legacy naming hangover as I understand, because too many 
> application depended on it.

system   = 16-bit
System32 = 32-bit
SysWOW64 = 64-bit
(Or I have no clue where else the 64-bit-dlls get stored...)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

On the merits of bringing back MSVC2015 to 48 to fix a top crasher

[Patrick McManus]

Hi All,

Tl;dr; The necko team has for months been chasing a windows only top
crasher. It is a shutdown hang - Bug 1158189. The crash stopped happening
on nightly-48 back in March and that ‘fixed state’ has been riding the
normal trains. Last weekend it returned to crashing on aurora-48 but not on
nightly-49. The data indicates that the toolchain changes are the reason.
We should talk about whether to put MSVC-2015 back on aurora-48 or to live
with the crashes for an extra 6 weeks.

This is a windows only bug and essentially boils down to non blocking
networking operations sometimes blocking (maybe forever) inside system
calls. It impacts a range of calls - send, recv, poll, connect, etc.. Often
LSPs and AV software is involved, but not always. Chrome has seen behavior
like this from time to time in the past, but anecdotally it is worse for
us. They aren’t sure if they have dealt with it since they changed to
msvc-2015.

On 46.0.1 this is the #18 top crasher (about 0.8% of crashes). On 47 this
is the #2 crasher (about 3.5% of crashes).  On 48 over the last 3 days it
is the #10 top crasher (1.25% of crashes), but is just in the noise for 48
when measured over the last few weeks as it just started recurring. It is
not a factor on 49.

We honestly don’t know if this is only a shutdown hang or not. It certainly
could be triggered by the shutdown path but just as easily this could be
happening during normal browsing and the user’s reaction would be to
shutdown the browser where networking (i.e. the socket thread) appears hung.

During the 48 cycle we hadn’t yet figured out a plan to attack it directly,
and while we were inserting diagnostics for it, we also cleaned up every
somewhat related issue we could find. When the hang disappeared from the
nightly crash stats we attributed it to a second order impact of a
different bugfix that landed at about the same time. Attempts to uplift
that fix to 47 did not help with crashes on 47 which we attributed to the
complex dependencies of the bug we uplifted (and eventually backed out of
47) - but it seems now the primary reason was that the toolchain on 47 was
different… as when the toolchain on 48 went back to msvc-2013 last Friday
the crashes returned on aurora 48. Version 49 (still msvc-2015) has not
seen a crash.

The last nightly crash was 20160324030447 - the msvc2015 patch landed 215
csets later on nightly-48. The crash was not seen again on 48 or 49 until
aurora-48 20160514004011 which had the reversion to msvc2013 just 31 csets
earlier. Nightly-49, which has only ever had msvc2015 as its compiler, has
not seen the crash.

I’m not sure how to compare the size of the populations impacted by the
crash vs the size of the population impacted by the SSE dependency. My
intuition says the no-SSE population is very small and we might be better
off overall with MSVC-2015 on the 48 channel.. We’re going to orphan that
population eventually anyhow but perhaps we want to live with the crashes
while we prep the infrastructure to deal with it as nathan mentions in a
different thread. I'm really torn.

Beyond the product tradeoffs, I am acutely aware that changing toolchains
is a real pain for everyone and going back and forth is kind of insane. I’m
sorry to even float the idea at this point - we hadn’t hypothesized that
the crash improved because of the change in msvc until it returned over the
weekend.


Thoughts?


-Patrick and Dragana

[This is a resend because filters hate me. My apologies if you receive it
twice.]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Donnerstag, 12. Mai 2016 18:56:19 UTC+2 schrieb Ben Hearsum:
> Do you have thoughts on how we'll be able to serve the users the correct 
> build if we have to base the decision on plugins they may have or other 
> information that's not in the update ping? We can already detect 32-bit 
> builds on 64-bit Windows through the build target, but information about 
> plugins or RAM is not something we know about when serving updates.

Is it possible to find out from which plugins no 64bit version exist yet?
So e.g. if the user have Flash 32bit the update can happen... like with 
extensions on startup a check and a (forced) update...

AFAIK updates get always done without a check before if there exist a update 
for each extension... Is there really a plugin (vendor) that can be a reason to 
not update the browser to a newer (64bit) build?

Btw.: AFAIK there is also no check about the compatibility of plugins before a 
normal update starts and if a plugin is un-secure, FF deactivate it, too.

> 
> On 2016-05-12 11:45 AM, Ted Mielczarek wrote:
> > Hello,
> >
> > Given all the discussion around SSE[2] lately, I was curious as to
> > whether we had made any plans to update Windows users that are running
> > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
> > builds. The 64-bit Windows builds do use SSE2, since that's a baseline
> > requirement for x86-64 processors, and the overall performance should
> > generally be better (modulo memory usage, I'm not sure if we have an
> > exact comparison). Additionally 64-bit builds are much less likely to
> > encounter OOM crashes due to address space fragmentation since they have
> > a very large address space compared to the maximum 4GB available to the
> > 32-bit builds.
> >
> > It does seem like we'd need some minimal checking here, obviously first
> > for whether the user is running 64-bit Windows, but also possibly
> > whether they use 32-bit plugins (until such time as we unsupport NPAPI).
> > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
> > the equivalent of Universal binaries like we do on OS X).
> >
> > -Ted
> >

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Donnerstag, 12. Mai 2016 18:22:53 UTC+2 schrieb David Baron:
> On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote:
> > requirement for x86-64 processors, and the overall performance should
> > generally be better (modulo memory usage, I'm not sure if we have an
> > exact comparison). Additionally 64-bit builds are much less likely to
> > encounter OOM crashes due to address space fragmentation since they have
> > a very large address space compared to the maximum 4GB available to the
> > 32-bit builds.
> 
> Might it be worth considering automatically updating users on
> machines with 6GB (roughly) or more of RAM, but leaving alone users
> with less RAM?

No!
FF crashes at ~2.5GB used ram!
Also AFAIK the mem can be used from the pagefile.sys... (even really slow!)
So there should be no min. system limit for a OOM crash!

> 
> -David
> 
> -- 
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)

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

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 23:03:16 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 22:59:35 UTC+2 schrieb Tobias B. Besemer:
> > Am Donnerstag, 19. Mai 2016 22:00:55 UTC+2 schrieb Nathan Froyd:
> > > On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer wrote:
> > > > Question is:
> > > > If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people 
> > > > are not able to configure there PCs right in BIOS ???
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > > 
> > > Perhaps those people deliberately disabled SSE in their BIOS for
> > > testing purposes.  Which is valuable, because very few Firefox
> > > developers are testing on non-SSE capable CPUs.
> > > 
> > > In any event, you misunderstand the cause here.  We're not backing out
> > > MSVC changes just because of these two users.  We're backing out MSVC
> > > changes because other infrastructure (the update server, the
> > > installer, etc.) isn't yet prepared for the SSE-required world we
> > > appear to be moving towards.  Making those changes deliberately in 49,
> > > rather than being surprised by it in 48, ensures a better experience
> > > for everyone (e.g. Firefox doesn't mysteriously start crashing when
> > > upgrades happen).
> > > 
> > > -Nathan
> > 
> > OK, means if there is no switch back to the older compiler, the compiled 
> > app wouldn't run without SSE2?
> 
> Sorry! Mean: Compiled with MSVC 2015 Firefox wouldn't run on Windows PC with 
> a Pentium II processor, or older (older then 1999)... ^^
> https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

Here some truths about SSE...

"In computing, Streaming SIMD Extensions (SSE) is an SIMD instruction set 
extension to the x86 architecture, designed by Intel and introduced in 1999 in 
their Pentium III series processors as a reply to AMD's 3DNow!"
https://de.wikipedia.org/wiki/Streaming_SIMD_Extensions

...so the last processor _without_ SSE is a Pentium II...
https://en.wikipedia.org/wiki/Pentium_II

Tech specs:
Produced:   From mid-1997 to early 1999
Max. CPU clock rate:233 MHz to 450 MHz
FSB speeds: 66 MHz to 100 MHz

Requirements for Win7:
[...] As expected, Windows 10 follows more in the line of 7 than it does 8, 
wrapping all but the most pitiful of PCs under its umbrella of coverage.
Given that Microsoft plans to support 10 universally across a wide variety of 
smartphones, tablets, laptops and desktops, it’s not exactly surprising that 
you can almost run the new OS on a toaster if you really wanted to.
Minimum system requirements for Windows 10 include a 1GHz processor or faster 
(single-core). 1GB of RAM will be necessary for the 32-bit version, while 
you’ll need to bump your computer up to 2GB if you plan on picking up the 
64-bit build. [...]
http://www.digitaltrends.com/computing/according-to-microsofts-specs-a-toaster-could-run-windows-10-so-you-probably-can-to/

But a Pentium II have only max. 450 MHz!

Requirements Vista...
Windows Vista Home Basic:
- 800-megahertz (MHz) 32-bit (x86) processor or 800-MHz 64-bit (x64) processor
- 512 megabytes (MB) of system memory
Note On system configurations that use system memory as graphics memory, at 
least 448 MB of system memory must be available to the operating system after 
some memory is allocated for graphics.
[...]
https://support.microsoft.com/en-us/kb/919183

...doesn't work with Pentium II!

Now XP...
Hardware requirements:
To install SP3 on a single computer, your computer must have a CD-ROM drive and 
at least the following:
A 233 megahertz (MHz) processor
64 megabytes (MB) of RAM
900 MB of available disk space during installation
https://technet.microsoft.com/de-de/library/cc507836.aspx

... so yes, you can install a WinXP on a Pentium II!

But this OS have some security vulnerabilities...
... to be exact: 70!
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-739/cvssscoremin-5/cvssscoremax-5.99/Microsoft-Windows-Xp.html

But if Mozilla spend enough time the next days, you will be able to run Firefox 
48 on a Windows XP, that have - if all fixes installed - 70 security 
vulnerabilities, with a Pentium II from 1998... ^^
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 23:25:15 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 23:03:16 UTC+2 schrieb Tobias B. Besemer:
> > Am Donnerstag, 19. Mai 2016 22:59:35 UTC+2 schrieb Tobias B. Besemer:
> > > Am Donnerstag, 19. Mai 2016 22:00:55 UTC+2 schrieb Nathan Froyd:
> > > > On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer wrote:
> > > > > Question is:
> > > > > If Mozilla will really "Backout MSVC 2015 from aurora" because 2 
> > > > > people are not able to configure there PCs right in BIOS ???
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > > > 
> > > > Perhaps those people deliberately disabled SSE in their BIOS for
> > > > testing purposes.  Which is valuable, because very few Firefox
> > > > developers are testing on non-SSE capable CPUs.
> > > > 
> > > > In any event, you misunderstand the cause here.  We're not backing out
> > > > MSVC changes just because of these two users.  We're backing out MSVC
> > > > changes because other infrastructure (the update server, the
> > > > installer, etc.) isn't yet prepared for the SSE-required world we
> > > > appear to be moving towards.  Making those changes deliberately in 49,
> > > > rather than being surprised by it in 48, ensures a better experience
> > > > for everyone (e.g. Firefox doesn't mysteriously start crashing when
> > > > upgrades happen).
> > > > 
> > > > -Nathan
> > > 
> > > OK, means if there is no switch back to the older compiler, the compiled 
> > > app wouldn't run without SSE2?
> > 
> > Sorry! Mean: Compiled with MSVC 2015 Firefox wouldn't run on Windows PC 
> > with a Pentium II processor, or older (older then 1999)... ^^
> > https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
> 
> Here some truths about SSE...
> 
> "In computing, Streaming SIMD Extensions (SSE) is an SIMD instruction set 
> extension to the x86 architecture, designed by Intel and introduced in 1999 
> in their Pentium III series processors as a reply to AMD's 3DNow!"
> https://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
> 
> ...so the last processor _without_ SSE is a Pentium II...
> https://en.wikipedia.org/wiki/Pentium_II
> 
> Tech specs:
> Produced: From mid-1997 to early 1999
> Max. CPU clock rate:  233 MHz to 450 MHz
> FSB speeds:   66 MHz to 100 MHz
> 
> Requirements for Win7:
> [...] As expected, Windows 10 follows more in the line of 7 than it does 8, 
> wrapping all but the most pitiful of PCs under its umbrella of coverage.
> Given that Microsoft plans to support 10 universally across a wide variety of 
> smartphones, tablets, laptops and desktops, it’s not exactly surprising that 
> you can almost run the new OS on a toaster if you really wanted to.
> Minimum system requirements for Windows 10 include a 1GHz processor or faster 
> (single-core). 1GB of RAM will be necessary for the 32-bit version, while 
> you’ll need to bump your computer up to 2GB if you plan on picking up the 
> 64-bit build. [...]
> http://www.digitaltrends.com/computing/according-to-microsofts-specs-a-toaster-could-run-windows-10-so-you-probably-can-to/
> 
> But a Pentium II have only max. 450 MHz!
> 
> Requirements Vista...
> Windows Vista Home Basic:
> - 800-megahertz (MHz) 32-bit (x86) processor or 800-MHz 64-bit (x64) processor
> - 512 megabytes (MB) of system memory
> Note On system configurations that use system memory as graphics memory, 
> at least 448 MB of system memory must be available to the operating system 
> after some memory is allocated for graphics.
> [...]
> https://support.microsoft.com/en-us/kb/919183
> 
> ...doesn't work with Pentium II!
> 
> Now XP...
> Hardware requirements:
> To install SP3 on a single computer, your computer must have a CD-ROM drive 
> and at least the following:
> A 233 megahertz (MHz) processor
> 64 megabytes (MB) of RAM
> 900 MB of available disk space during installation
> https://technet.microsoft.com/de-de/library/cc507836.aspx
> 
> ... so yes, you can install a WinXP on a Pentium II!
> 
> But this OS have some security vulnerabilities...
> ... to be exact: 70!
> https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-739/cvssscoremin-5/cvssscoremax-5.99/Microsoft-Windows-Xp.html
> 
> But if Mozilla spend enough time the next days, you will be able to run 
> Firefox 48 on a Windows XP, that have - if all fixes installed - 70 security 
> vulnerabilities, with a Pentium II from 1998... ^^

Comment 1 says "Downgrade to VS2013 due to unwanted SSE instruction 
insertion"...
https://bugzilla.mozilla.org/show_bug.cgi?id=1270664#c1

Or is this wrong ???

https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
https://en.wikipedia.org/wiki/SSE2
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 22:59:35 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 22:00:55 UTC+2 schrieb Nathan Froyd:
> > On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer wrote:
> > > Question is:
> > > If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people 
> > > are not able to configure there PCs right in BIOS ???
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > 
> > Perhaps those people deliberately disabled SSE in their BIOS for
> > testing purposes.  Which is valuable, because very few Firefox
> > developers are testing on non-SSE capable CPUs.
> > 
> > In any event, you misunderstand the cause here.  We're not backing out
> > MSVC changes just because of these two users.  We're backing out MSVC
> > changes because other infrastructure (the update server, the
> > installer, etc.) isn't yet prepared for the SSE-required world we
> > appear to be moving towards.  Making those changes deliberately in 49,
> > rather than being surprised by it in 48, ensures a better experience
> > for everyone (e.g. Firefox doesn't mysteriously start crashing when
> > upgrades happen).
> > 
> > -Nathan
> 
> OK, means if there is no switch back to the older compiler, the compiled app 
> wouldn't run without SSE2?

Sorry! Mean: Compiled with MSVC 2015 Firefox wouldn't run on Windows PC with a 
Pentium II processor, or older (older then 1999)... ^^
https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 22:00:55 UTC+2 schrieb Nathan Froyd:
> On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer wrote:
> > Question is:
> > If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are 
> > not able to configure there PCs right in BIOS ???
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> 
> Perhaps those people deliberately disabled SSE in their BIOS for
> testing purposes.  Which is valuable, because very few Firefox
> developers are testing on non-SSE capable CPUs.
> 
> In any event, you misunderstand the cause here.  We're not backing out
> MSVC changes just because of these two users.  We're backing out MSVC
> changes because other infrastructure (the update server, the
> installer, etc.) isn't yet prepared for the SSE-required world we
> appear to be moving towards.  Making those changes deliberately in 49,
> rather than being surprised by it in 48, ensures a better experience
> for everyone (e.g. Firefox doesn't mysteriously start crashing when
> upgrades happen).
> 
> -Nathan

OK, means if there is no switch back to the older compiler, the compiled app 
wouldn't run without SSE2?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Nathan Froyd]

On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer
 wrote:
> Question is:
> If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are 
> not able to configure there PCs right in BIOS ???
> https://bugzilla.mozilla.org/show_bug.cgi?id=1270664

Perhaps those people deliberately disabled SSE in their BIOS for
testing purposes.  Which is valuable, because very few Firefox
developers are testing on non-SSE capable CPUs.

In any event, you misunderstand the cause here.  We're not backing out
MSVC changes just because of these two users.  We're backing out MSVC
changes because other infrastructure (the update server, the
installer, etc.) isn't yet prepared for the SSE-required world we
appear to be moving towards.  Making those changes deliberately in 49,
rather than being surprised by it in 48, ensures a better experience
for everyone (e.g. Firefox doesn't mysteriously start crashing when
upgrades happen).

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

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Example for "GenuineIntel Family 6 Model 15 Stepping 13":
http://browser.primatelabs.com/geekbench3/125284
(Intel Core 2 Duo T5800 @ 2.00 GHz)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 20:49:08 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 19:58:50 UTC+2 schrieb Tobias B. Besemer:
> > Am Donnerstag, 19. Mai 2016 19:53:40 UTC+2 schrieb Tobias B. Besemer:
> > > Am Donnerstag, 19. Mai 2016 17:46:58 UTC+2 schrieb Gijs Kruitbosch:
> > > > On 19/05/2016 16:35, Tobias B. Besemer wrote:
> > > > > Due to the upcoming requirement of SSE2 to run Firefox that is 
> > > > > discussed here:
> > > > > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0
> > > > >
> > > > > ...I had a look on...
> > > > > Bug 1271755 - [meta] Require SSE2 to run Firefox
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1271755
> > > > >
> > > > > ...then on...
> > > > > Bug 1270664 - Backout MSVC 2015 from aurora
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > > > >
> > > > > ...and then the crash that comes up on non-SSE2-Systems...
> > > > > Bug 1265615 - crash in SkPath::isRectContour
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1265615
> > > > >
> > > > > As I was interested in what kind of configurations that are, I opened:
> > > > > https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour
> > > > >
> > > > > ...here I get just 1 crash in the last 7 days with FF49.0a1 and 
> > > > > "Process Type = content".
> > > > >
> > > > > So what is "Process Type = content" in "mozilla crash reports"?
> > > > 
> > > > It means that when using electrolysis/e10s/"process separation for web 
> > > > content", the process running/displaying (ish) web content crashed 
> > > > (rather than Firefox as a whole crashing). It has nothing to do with 
> > > > SSE(2).
> > > > 
> > > > > And how I can have a look on the crash reports of e.g. the last ~30 
> > > > > days?
> > > > 
> > > > There are too many for looking at all crash reports to be a meaningful 
> > > > operation. If you mean all crash reports with that signature,
> > > > 
> > > > https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> > > > 
> > > > ~ Gijs
> > > 
> > > OK, my fault!
> > > No native speaker and I read "processOR type"... ^^
> > > Processor is that what I'm was looking for...
> > > 
> > > So I had a look at...
> > > https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> > > 
> > > ...then "View ALL products and versions for this signature."...
> > > https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour
> > > 
> > > ...and then had on this huge amount of two reports a look... ;-)
> > > https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour#tab-reports
> > > 
> > > I see:
> > > Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
> > > Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2
> > > 
> > > ...what IMHO means that the user have just deactivated SSE2-Support in 
> > > BIOS...
> > 
> > Question is:
> > If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are 
> > not able to configure there PCs right in BIOS ???
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> 
> OK, seems to be not 100% correct!
> 
> Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
> Seems to be:
> Athlon 1200 (Thunderbird)
> AMD Name String: AMD Athlon(tm) Processor
> Features: FPU TSC CX8 CMOV FXSR MMX
> http://www.masmforum.com/board/index.php?PHPSESSID=8d46cd4ecb1688be429ab49694ec53e6=1909.5;wap2
> (I'm wonder that this system can run Win7!)
> 
> And...
> Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2
> Seems to be somethink like this:
> Processor Intel(R) Xeon(R) CPU 5130 @ 2.00GHz @ 2.00 GHz
> 2 Processors, 4 Threads
> Processor ID GenuineIntel Family 6 Model 15 Stepping 6
> L1 Instruction Cache 32.0 KB x 2
> L1 Data Cache 32.0 KB x 2
> L2 Cache 4.00 MB
> L3 Cache 0.00 B
> Memory 3.86 GB
> http://www1.hft-leipzig.de/s114122/geekbenchscore.html
> (With WinXP.)

But maybe the first is an emu...
https://qemu.weilnetz.de/w64/2012/2012-08-24/cpus-x86_64.conf
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 19:58:50 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 19:53:40 UTC+2 schrieb Tobias B. Besemer:
> > Am Donnerstag, 19. Mai 2016 17:46:58 UTC+2 schrieb Gijs Kruitbosch:
> > > On 19/05/2016 16:35, Tobias B. Besemer wrote:
> > > > Due to the upcoming requirement of SSE2 to run Firefox that is 
> > > > discussed here:
> > > > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0
> > > >
> > > > ...I had a look on...
> > > > Bug 1271755 - [meta] Require SSE2 to run Firefox
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1271755
> > > >
> > > > ...then on...
> > > > Bug 1270664 - Backout MSVC 2015 from aurora
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > > >
> > > > ...and then the crash that comes up on non-SSE2-Systems...
> > > > Bug 1265615 - crash in SkPath::isRectContour
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1265615
> > > >
> > > > As I was interested in what kind of configurations that are, I opened:
> > > > https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour
> > > >
> > > > ...here I get just 1 crash in the last 7 days with FF49.0a1 and 
> > > > "Process Type = content".
> > > >
> > > > So what is "Process Type = content" in "mozilla crash reports"?
> > > 
> > > It means that when using electrolysis/e10s/"process separation for web 
> > > content", the process running/displaying (ish) web content crashed 
> > > (rather than Firefox as a whole crashing). It has nothing to do with 
> > > SSE(2).
> > > 
> > > > And how I can have a look on the crash reports of e.g. the last ~30 
> > > > days?
> > > 
> > > There are too many for looking at all crash reports to be a meaningful 
> > > operation. If you mean all crash reports with that signature,
> > > 
> > > https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> > > 
> > > ~ Gijs
> > 
> > OK, my fault!
> > No native speaker and I read "processOR type"... ^^
> > Processor is that what I'm was looking for...
> > 
> > So I had a look at...
> > https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> > 
> > ...then "View ALL products and versions for this signature."...
> > https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour
> > 
> > ...and then had on this huge amount of two reports a look... ;-)
> > https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour#tab-reports
> > 
> > I see:
> > Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
> > Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2
> > 
> > ...what IMHO means that the user have just deactivated SSE2-Support in 
> > BIOS...
> 
> Question is:
> If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are 
> not able to configure there PCs right in BIOS ???
> https://bugzilla.mozilla.org/show_bug.cgi?id=1270664

OK, seems to be not 100% correct!

Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
Seems to be:
Athlon 1200 (Thunderbird)
AMD Name String: AMD Athlon(tm) Processor
Features: FPU TSC CX8 CMOV FXSR MMX
http://www.masmforum.com/board/index.php?PHPSESSID=8d46cd4ecb1688be429ab49694ec53e6=1909.5;wap2
(I'm wonder that this system can run Win7!)

And...
Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2
Seems to be somethink like this:
Processor Intel(R) Xeon(R) CPU 5130 @ 2.00GHz @ 2.00 GHz
2 Processors, 4 Threads
Processor ID GenuineIntel Family 6 Model 15 Stepping 6
L1 Instruction Cache 32.0 KB x 2
L1 Data Cache 32.0 KB x 2
L2 Cache 4.00 MB
L3 Cache 0.00 B
Memory 3.86 GB
http://www1.hft-leipzig.de/s114122/geekbenchscore.html
(With WinXP.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Thu, May 19, 2016 at 1:41 PM, Andrew McCreight 
wrote:

> On Thu, May 19, 2016 at 8:04 AM, Ben Kelly  wrote:
>
> > 3) Supports async pipe streams using a new PSendStream actor from
> > *child-to-parent*.  I have plans to add support for parent-to-child, but
> I
> > don't have a consumer yet and we need to figure out some issues with
> > PBackground targeting worker threads.
> >
>
> One place that this would be very useful would be for networking. Right
> now, the various networking protocols send data to the child by calling
> NS_ReadInputStreamToString(), then copying the string into an IPC message,
> which is bad because it requires a lot of contiguous memory addresses, and
> also has a fair bit of bloat from all of the copies (bug 1110596, bug
> 1263028).
>

That would be a good thing to try.  I wonder how many consumers assume
nsIChannel::OnDataAvailable() provides a fixed length stream, though.

Here is the bug to track parent-to-child pipe streaming:

https://bugzilla.mozilla.org/show_bug.cgi?id=1274343

Thanks.

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

Re: Intent to unship: HTML microdata API

[Boris Zbarsky]

On 5/19/16 2:08 PM, Emma Humphries wrote:

Should I remove the component from Bugzilla and mark remaining bugs incomplete?


Emma,

Which component do you mean?  But I suspect the answer is "no"...

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Thu, May 19, 2016 at 1:41 PM, Andrew McCreight 
wrote:

> On Thu, May 19, 2016 at 8:04 AM, Ben Kelly  wrote:
>
> > 3) Supports async pipe streams using a new PSendStream actor from
> > *child-to-parent*.  I have plans to add support for parent-to-child, but
> I
> > don't have a consumer yet and we need to figure out some issues with
> > PBackground targeting worker threads.
> >
>
> One place that this would be very useful would be for networking. Right
> now, the various networking protocols send data to the child by calling
> NS_ReadInputStreamToString(), then copying the string into an IPC message,
> which is bad because it requires a lot of contiguous memory addresses, and
> also has a fair bit of bloat from all of the copies (bug 1110596, bug
> 1263028).
>
> Andrew
> ___
> 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: Intent to unship: HTML microdata API

[Emma Humphries]

> On May 19, 2016, at 10:55 AM, Boris Zbarsky  wrote:
> 
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633
> 
> Target release: 49
> 
> I believe I've removed all our in-browser dependencies on this stuff.  I 
> haven't really checked addons because unfortunately the property names 
> this thing uses (e.g. "properties", "itemId") are way too common.  :(

Should I remove the component from Bugzilla and mark remaining bugs incomplete?

-- Emma


> 
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> Summary: The HTML Microdata API was removed from the spec due to lack of 
> implementor interest.  See 
> .  Our 
> implementation of it breaks some pages (due to the itemId attributes it 
> adds) and is a bunch of code.  I would like to remove it.
> 
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633
> 
> Target release: 49
> 
> I believe I've removed all our in-browser dependencies on this stuff.  I 
> haven't really checked addons because unfortunately the property names 
> this thing uses (e.g. "properties", "itemId") are way too common.  :(
> 
> -Boris
> ___
> 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

Intent to unship: HTML microdata API

[Boris Zbarsky]

Summary: The HTML Microdata API was removed from the spec due to lack of 
implementor interest.  See 
.  Our 
implementation of it breaks some pages (due to the itemId attributes it 
adds) and is a bunch of code.  I would like to remove it.


Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633

Target release: 49

I believe I've removed all our in-browser dependencies on this stuff.  I 
haven't really checked addons because unfortunately the property names 
this thing uses (e.g. "properties", "itemId") are way too common.  :(


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

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 19:53:40 UTC+2 schrieb Tobias B. Besemer:
> Am Donnerstag, 19. Mai 2016 17:46:58 UTC+2 schrieb Gijs Kruitbosch:
> > On 19/05/2016 16:35, Tobias B. Besemer wrote:
> > > Due to the upcoming requirement of SSE2 to run Firefox that is discussed 
> > > here:
> > > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0
> > >
> > > ...I had a look on...
> > > Bug 1271755 - [meta] Require SSE2 to run Firefox
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1271755
> > >
> > > ...then on...
> > > Bug 1270664 - Backout MSVC 2015 from aurora
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> > >
> > > ...and then the crash that comes up on non-SSE2-Systems...
> > > Bug 1265615 - crash in SkPath::isRectContour
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1265615
> > >
> > > As I was interested in what kind of configurations that are, I opened:
> > > https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour
> > >
> > > ...here I get just 1 crash in the last 7 days with FF49.0a1 and "Process 
> > > Type = content".
> > >
> > > So what is "Process Type = content" in "mozilla crash reports"?
> > 
> > It means that when using electrolysis/e10s/"process separation for web 
> > content", the process running/displaying (ish) web content crashed 
> > (rather than Firefox as a whole crashing). It has nothing to do with SSE(2).
> > 
> > > And how I can have a look on the crash reports of e.g. the last ~30 days?
> > 
> > There are too many for looking at all crash reports to be a meaningful 
> > operation. If you mean all crash reports with that signature,
> > 
> > https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> > 
> > ~ Gijs
> 
> OK, my fault!
> No native speaker and I read "processOR type"... ^^
> Processor is that what I'm was looking for...
> 
> So I had a look at...
> https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> 
> ...then "View ALL products and versions for this signature."...
> https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour
> 
> ...and then had on this huge amount of two reports a look... ;-)
> https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour#tab-reports
> 
> I see:
> Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
> Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2
> 
> ...what IMHO means that the user have just deactivated SSE2-Support in BIOS...

Question is:
If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are not 
able to configure there PCs right in BIOS ???
https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Donnerstag, 19. Mai 2016 17:46:58 UTC+2 schrieb Gijs Kruitbosch:
> On 19/05/2016 16:35, Tobias B. Besemer wrote:
> > Due to the upcoming requirement of SSE2 to run Firefox that is discussed 
> > here:
> > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0
> >
> > ...I had a look on...
> > Bug 1271755 - [meta] Require SSE2 to run Firefox
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1271755
> >
> > ...then on...
> > Bug 1270664 - Backout MSVC 2015 from aurora
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
> >
> > ...and then the crash that comes up on non-SSE2-Systems...
> > Bug 1265615 - crash in SkPath::isRectContour
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1265615
> >
> > As I was interested in what kind of configurations that are, I opened:
> > https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour
> >
> > ...here I get just 1 crash in the last 7 days with FF49.0a1 and "Process 
> > Type = content".
> >
> > So what is "Process Type = content" in "mozilla crash reports"?
> 
> It means that when using electrolysis/e10s/"process separation for web 
> content", the process running/displaying (ish) web content crashed 
> (rather than Firefox as a whole crashing). It has nothing to do with SSE(2).
> 
> > And how I can have a look on the crash reports of e.g. the last ~30 days?
> 
> There are too many for looking at all crash reports to be a meaningful 
> operation. If you mean all crash reports with that signature,
> 
> https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour
> 
> ~ Gijs

OK, my fault!
No native speaker and I read "processOR type"... ^^
Processor is that what I'm was looking for...

So I had a look at...
https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour

...then "View ALL products and versions for this signature."...
https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour

...and then had on this huge amount of two reports a look... ;-)
https://crash-stats.mozilla.com/report/list?date=2016-05-19_unit=days_value=28=SkPath%3A%3AisRectContour#tab-reports

I see:
Build Architecture Info = AuthenticAMD family 6 model 4 stepping 2 | 1
Build Architecture Info = GenuineIntel family 6 model 15 stepping 13 | 2

...what IMHO means that the user have just deactivated SSE2-Support in BIOS...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPCStream landed in mozilla-central

[Andrew McCreight]

On Thu, May 19, 2016 at 8:04 AM, Ben Kelly  wrote:

> 3) Supports async pipe streams using a new PSendStream actor from
> *child-to-parent*.  I have plans to add support for parent-to-child, but I
> don't have a consumer yet and we need to figure out some issues with
> PBackground targeting worker threads.
>

One place that this would be very useful would be for networking. Right
now, the various networking protocols send data to the child by calling
NS_ReadInputStreamToString(), then copying the string into an IPC message,
which is bad because it requires a lot of contiguous memory addresses, and
also has a fair bit of bloat from all of the copies (bug 1110596, bug
1263028).

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

Re: What is "Process Type = content" in "mozilla crash reports"?

[Gijs Kruitbosch]

On 19/05/2016 16:35, Tobias B. Besemer wrote:

Due to the upcoming requirement of SSE2 to run Firefox that is discussed here:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0

...I had a look on...
Bug 1271755 - [meta] Require SSE2 to run Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1271755

...then on...
Bug 1270664 - Backout MSVC 2015 from aurora
https://bugzilla.mozilla.org/show_bug.cgi?id=1270664

...and then the crash that comes up on non-SSE2-Systems...
Bug 1265615 - crash in SkPath::isRectContour
https://bugzilla.mozilla.org/show_bug.cgi?id=1265615

As I was interested in what kind of configurations that are, I opened:
https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour

...here I get just 1 crash in the last 7 days with FF49.0a1 and "Process Type = 
content".

So what is "Process Type = content" in "mozilla crash reports"?


It means that when using electrolysis/e10s/"process separation for web 
content", the process running/displaying (ish) web content crashed 
(rather than Firefox as a whole crashing). It has nothing to do with SSE(2).



And how I can have a look on the crash reports of e.g. the last ~30 days?


There are too many for looking at all crash reports to be a meaningful 
operation. If you mean all crash reports with that signature,


https://crash-stats.mozilla.com/report/list?product=Firefox_unit=days_value=28=SkPath%3A%3AisRectContour

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

Suggestion: Class or API to check pre-requirements of Firefox

[Tobias B. Besemer]

As I'm lazy, plz read here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1271762
;-)

(It's really not much to read in the bug!)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Due to the upcoming requirement of SSE2 to run Firefox that is discussed here:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0

...I had a look on...
Bug 1271755 - [meta] Require SSE2 to run Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1271755

...then on...
Bug 1270664 - Backout MSVC 2015 from aurora
https://bugzilla.mozilla.org/show_bug.cgi?id=1270664

...and then the crash that comes up on non-SSE2-Systems...
Bug 1265615 - crash in SkPath::isRectContour
https://bugzilla.mozilla.org/show_bug.cgi?id=1265615

As I was interested in what kind of configurations that are, I opened:
https://crash-stats.mozilla.com/signature/?product=Firefox=SkPath%3A%3AisRectContour

...here I get just 1 crash in the last 7 days with FF49.0a1 and "Process Type = 
content".

So what is "Process Type = content" in "mozilla crash reports"?
And how I can have a look on the crash reports of e.g. the last ~30 days?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Request Feedback - Submitting Canvas Frames, WebVR Compositor

[Vladimir Vukicevic]

This looks good to me in general -- for Gecko, this combined with offscreen
canvas and canvas/webgl in workers is going to be the best way to get
performant WebGL-based VR.  This is likely going to be the better way to
solve the custom-vsync for VR issue; while the large patch queue that I
have does work, it adds significant complexity to Gecko's vsync, and is
unlikely to get used by any other system.  You'll want to make sure that
the gfx folks weigh in on this as well.

Some comments -- if you want direct front-buffer rendering from canvas,
this will be tricky; you'll have to add support to canvas itself, because
right now the rendering context always allocates its own buffers.  That is,
you won't be able to render directly to the texture that goes in to an
Oculus compositor layer textureset, for example, even though that's what
you really want to do.  But I'd get the core working first and then work on
eliminating that copy and sharing the textureset surfaces with webgl canvas.

Same thing with support for Oculus Home as well as allowing for HTML
layers; those should probably be later steps (HTML/2D layers will need to
be rendered on the main thread and submitted from there, so timing them
between worker-offscreen-canvas layers and the main thread could be tricky).

- Vlad

On Tue, May 10, 2016 at 6:18 PM Kearwood "Kip" Gilbert 
wrote:

> Hello All,
>
> In order to support features in the WebVR 1.0 API (
> https://mozvr.com/webvr-spec/) and to improve performance for WebVR, I
> would like to implement an optimized path for submitting Canvas and
> OffscreenCanvas frames to VR headsets.  The WebVR 1.0 API introduces "VR
> Layers", explicit frame submission, and presenting different content to the
> head mounted display independently of the output the regular 2d monitor.  I
> would like some feedback on a proposed “VR Compositor” concept that would
> enable this.
>
> *What would be common between the “VR Compositor” and the regular “2d
> Compositor”?*
> - TextureHost and TextureChild would be used to transfer texture data
> across processes.
> - When content processes crash, the VR Compositor would continue to run.
> - There is a parallel between regular layers created by layout and “VR
> Layers”.
> - There would be one VR Compositor serving multiple content processes.
> - The VR Compositor would not allow unprivileged content to read back
> frames submitted by other content and chrome ux.
> - Both compositors would exist in the “Compositor” process, but in
> different threads.
>
> *What is different about the “VR Compositor”?*
> - The VR Compositor would extend the PVRManager protocol to include VR
> Layer updates.
> - The VR Compositor will not obscure the main 2d output window or require
> entering full screen to activate a VR Headset.
> - In most cases, there will be no visible window created by the VR
> Compositor as the VR frames are presented using VR specific API’s that
> bypass the OS-level window manager.
> - The VR Compositor will not run synchronously with a refresh driver as it
> can simultaneously present content with mixed frame rates.
> - Texture updates submitted for VR Layers would be rendered as soon as
> possible, often asynchronously with other VR Layer updates.
> - VR Layer textures will be pushed from both Canvas elements and
> OffscreenCanvas objects, enabling WebVR in WebWorkers.
> - The VR compositor will guarantee perfect frame uniformity, with each
> frame associated with a VR headset pose frame explicitly passed into
> VRDisplay.SubmitFrame.  No frames will be dropped, even if multiple frames
> are sent within a single hardware vsync.
> - For most devices (i.e. Oculus and HTC Vive), the VR Compositor will
> perform front-buffer rendering.
> - VR Layers asynchronously move with the user’s HMD pose between VR Layer
> texture updates if given geometry and a position within space.
> - The VR Compositor implements latency hiding effects such as Asynchronous
> Time Warp and Pose Prediction.
> - The VR Compositor will be as minimal as possible.  In most cases, the VR
> Compositor will offload the actual compositing to the VR device runtimes.
>  (Both Oculus and HTC Vive include a VR compositor)
> - When the VR device runtime does not supply a VR Compositor, we will
> emulate this functionality.  (i.e. for Cardboard VR)
> - All VR hardware API calls will be made exclusively from the VR
> Compositor’s thread.
> - The VR Compositor will implement focus handling, window management, and
> other functionality required for Firefox to be launched within environments
> such as Oculus Home and SteamVR.
> - To support backwards compatibility and fall-back views of 2d web content
> within the VR headset, the VR compositor could provide an nsWidget /
> nsWindow interface to the 2d compositor.  The 2d compositor output would be
> projected onto the geometry of a VR Layer and updated asynchronously with
> HMD poses.
> - The VR Compositor will not allocate unnecessary 

IPCStream landed in mozilla-central

[Ben Kelly]

Hi all,

FYI, I've landed a new IPDL type in bug 1093357 called IPCStream.  This is
intended to make it easier to serialize nsIInputStreams across IPC.

In short, IPCStream:

1) Supports our existing serializable nsInputStreams.
2) Also automatically handles send file descriptors using the
PFileDescriptorSet actor
3) Supports async pipe streams using a new PSendStream actor from
*child-to-parent*.  I have plans to add support for parent-to-child, but I
don't have a consumer yet and we need to figure out some issues with
PBackground targeting worker threads.

Because the actors require special care there is also a new RAII type
called AutoIPCStream.

A short example of using these types:

  // ipdl
  protocol PMyStuff
  {
  parent:
async DoStuff(IPCStream aStream);
  }

  // in the child
  void
  CallDoStuff(PMyStuffChild* aActor, nsIInputStream* aStream)
  {
AutoIPCstream autoStream;
autoStream.Serialize(aStream, aActor->Manager());
aActor->SendDoStuff(autoStream.TakeValue());
  }

  // in the parent
  bool
  MyStuffParent::RecvDoStuff(const IPCStream& aIPCStream)
  {
nsCOMPtr stream = DeserializeIPCStream(aIPCStream);
// do something with the stream
  }

This example and more documentation can be found in the comments in
IPCStreamUtils.h:

https://dxr.mozilla.org/mozilla-central/source/ipc/glue/IPCStreamUtils.h#31

For the most part you should be able to replace ipdl like:

  InputStreamParams streamParams;
  FileDescriptorSet streamFds;

With:

  IPCStream stream;

Note, however, some code will assume it gets a fixed length stream from IPC
because that is all we have supported in the past.  You should audit the
code to make sure it supports variable length streams.

For example, necko expects to be able to call Available() on the stream in
the parent in order to set content-length.  In order to support the
IPCStream pipe mechanism necko needs to implement chunked uploads or
accumulate the stream before setting the content-length.

Right now the AutoIPCStream::Serialize() method will automatically try
serialization in this order:

1) Fixed length serialization
2) Variable length serialization

We could expand the API to favor one over the other or restrict to only one
kind of serialization.

There is one consumer using IPCStream at the moment; dom/cache.  Its a bit
of a complex example, though, since Cache API needs to send arrays of
streams in a single IPC call.  I tried to include adequate examples in
IPCStreamUtils.h to compensate for this.

Anyway, I hope this helps people dealing with nsInputStreams and ipdl
interfaces.  Please let me know if you run into any problems or have
questions.

Thanks.

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

Re: Requiring SSE2 on all 32-bit x86 OSs

[Henri Sivonen]

On Thu, May 19, 2016 at 12:31 PM, Mike Hommey  wrote:
> I don't think anyone suggested to add support for runtime selection of
> SSE2 for code that is not inline asm.

The code that I'm most immediately interested in replacing with Rust
with SSE2 intrinsics without runtime selection currently uses C++ with
SSE2 intrinsics with runtime selection. It seems prudent to establish
that is indeed is okay to plan to proceed without runtime selection.

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

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Henri Sivonen]

On Thu, May 19, 2016 at 12:30 PM, Kurt Roeckx  wrote:
> On 2016-05-18 10:10, Henri Sivonen wrote:
>>
>> What do we need to do to reach a decision that it's indeed OK to treat
>> *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
>> "patches not even welcome" kind of thing, considering that this may
>> lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
>> performance relative to Mozilla-shipped 32-bit x86 Firefox?
>
>
> That doesn't make sense, and seems to just have the opposite effect.  If
> runtime detection is non-optional only non-SSE2 is left. If runtime
> detection is supported you wouldn't have degraded performance.

I'm saying patches to add run-time SSE2 selection would not be welcome
for Rust code. I.e. run-time detection would *not* be supported.
Hence, distros that want to support non-SSE2 would compile the
non-SSE2 code only giving SSE2-enabled CPUs non-SSE2 code.

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

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Kurt Roeckx]

On 2016-05-18 10:10, Henri Sivonen wrote:

What do we need to do to reach a decision that it's indeed OK to treat
*run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
"patches not even welcome" kind of thing, considering that this may
lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
performance relative to Mozilla-shipped 32-bit x86 Firefox?


That doesn't make sense, and seems to just have the opposite effect.  If 
runtime detection is non-optional only non-SSE2 is left.  If runtime 
detection is supported you wouldn't have degraded performance.



Kurt

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

Re: Requiring SSE2 on all 32-bit x86 OSs

[Mike Hommey]

On Thu, May 19, 2016 at 12:07:42PM +0300, Henri Sivonen wrote:
> On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
>  wrote:
> > Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
> > comfortable making that decision today.
> 
> Thank you! I filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 for this.
> 
> > Should we also take actions that prevent anyone from supporting non-SSE2
> > codepaths? I don't know. There seem to be at least a few cases that this
> > affects:
> >
> > Rust and its support for non-SSE2 arches
> >
> > This seems to be both about build-time targeting and runtime dynamic
> > selection. I don't personally understand the cost/benefit tradeoff here.
> 
> There are two levels of complication with run-time selection:
> 
>  1) Since inline asm isn't allowed in stable-channel Rust, executing
> the cpuid instruction must be done in some other way, which leads
> either to having to make the crate (that could otherwise be a
> standalone Rust library) depend on Gecko's existing CPU sniffing
> infrastructure or to having to link some ad hoc cpuid-execution
> non-Rust object to the crate that could otherwise be a simple
> pure-Rust crate.
> 
>  2) Since LLVM and, by extension, rustc currently require the compiler
> instruction set targeting options to be the same throughout the
> compilation unit, if the main crate is compiled without SSE2 to cater
> for the non-SSE2 case, the SSE2-enabled versions of functions need to
> be put in a separate crate, which is considerably less nice than what
> rustc lets you do if you want to supply SSE2 and ALU-only alternatives
> for a function such that the selection is done at compile time. In
> particular, if you want to avoid having two copies of SSE2 code, one
> in the main crate for build-time selection and the other in the
> SSE2-only helper crate, you have to put the single copy in the helper
> crate, which means that the preferred case (SSE2 enabled at build
> time) is made more complex, too.

I don't think anyone suggested to add support for runtime selection of
SSE2 for code that is not inline asm.

> The problem with build-time selection is that the non-SSE2 target
> isn't the target that the Rust community tests the most actively.
> (Just like, evidently, Microsoft doesn't actively test the non-SSE
> target of MSVC.)

If distro's Rust compiler doesn't target SSE2, they'll obviously be
testing that. But it's not really a concern for you to have. It's
theirs.

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

Re: Requiring SSE2 on all 32-bit x86 OSs

[Henri Sivonen]

On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
 wrote:
> Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
> comfortable making that decision today.

Thank you! I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 for this.

> Should we also take actions that prevent anyone from supporting non-SSE2
> codepaths? I don't know. There seem to be at least a few cases that this
> affects:
>
> Rust and its support for non-SSE2 arches
>
> This seems to be both about build-time targeting and runtime dynamic
> selection. I don't personally understand the cost/benefit tradeoff here.

There are two levels of complication with run-time selection:

 1) Since inline asm isn't allowed in stable-channel Rust, executing
the cpuid instruction must be done in some other way, which leads
either to having to make the crate (that could otherwise be a
standalone Rust library) depend on Gecko's existing CPU sniffing
infrastructure or to having to link some ad hoc cpuid-execution
non-Rust object to the crate that could otherwise be a simple
pure-Rust crate.

 2) Since LLVM and, by extension, rustc currently require the compiler
instruction set targeting options to be the same throughout the
compilation unit, if the main crate is compiled without SSE2 to cater
for the non-SSE2 case, the SSE2-enabled versions of functions need to
be put in a separate crate, which is considerably less nice than what
rustc lets you do if you want to supply SSE2 and ALU-only alternatives
for a function such that the selection is done at compile time. In
particular, if you want to avoid having two copies of SSE2 code, one
in the main crate for build-time selection and the other in the
SSE2-only helper crate, you have to put the single copy in the helper
crate, which means that the preferred case (SSE2 enabled at build
time) is made more complex, too.

The problem with build-time selection is that the non-SSE2 target
isn't the target that the Rust community tests the most actively.
(Just like, evidently, Microsoft doesn't actively test the non-SSE
target of MSVC.)

> I imagine we'd like to remove this complexity from the tree, especially
> given that we won't have any testing for it.

I agree, though with C++, the complexity of having one function in a
different compilation unit is more on the level of the general
complexity of C++ whereas with Rust, the difference is more
distinctive.

On Wed, May 18, 2016 at 1:54 PM, Mike Hommey  wrote:
>> What do we need to do to reach a decision that it's indeed OK to treat
>> *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
>> "patches not even welcome" kind of thing, considering that this may
>> lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
>> performance relative to Mozilla-shipped 32-bit x86 Firefox?
>
> This paragraph doesn't make sense to me. That is, I don't see the
> relationship between "patches not even welcome" and degraded performance
> relative to Mozilla-shipped 32-bit x86 Firefox.

If the code doesn't support run-time selection of SSE2 vs. non-SSE2
variants,  Mozilla will build the SSE2 variants and a distro that
wishes to support non-SSE2 would build the non-SSE2 code (unless the
distro offers two packages: with SSE2 and without).

> Also note that in practice, there *already* is a performance difference
> between Mozilla-shipped Firefox and distro-shipped Firefox

:-(

> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.

See my reply to bsmedberg above for why I wouldn't want to take
patches for run-time selection of SSE2 in Rust code.

> Why specifically not welcome patches, instead of, say, making it
> tier-3, like e.g. sparc or mips?

MIPS vs. x86 is an app-wide compile-time choice that doesn't involve
splitting crates. I'm against splitting crates for reasons that don't
affect official builds, which is what *run-time* selection of SSE2
would do.

Markus Stange wrote:
> Wouldn't these code paths still be tested on Android? I expect we have many 
> code paths that have an SSE2 specialization but not an ARM NEON one, so we 
> use the non-SSE2 code paths on ARM. The Moz2D software filter code is an 
> example of such a case.

*Compile-time*-selected ALU-only code paths would get tested on Android, yes.

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

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen <
emanuel.hoogev...@gmail.com> wrote:

> They do get the baseline compiler, which can still be significantly faster
> than the interpreter, but Ion requires SSE2. Since the runtime detection
> does just turn Ion off altogether, I don't know if we would gain much by
> removing it (the ability to disable Ion isn't going away).
>

We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least use the
much slower 'normal JS' path. For WebAssembly, we have the following
options IIUC:

(1) Don't support wasm on those ancient CPUs. This may work for a while,
but at some point we may include wasm modules in Firefox, normal websites
will start to use it, etc.

(2) Add x87 floating-point support to the wasm baseline JIT - very
complicated and likely not worth it.

(3) Call into C++ for all floating point and SIMD operations. This will be
horribly slow.

(4) Add a wasm interpreter. Again, likely not worth the effort if it's just
for this.

Jan



> IIRC our fuzzers already compile with SSE2 enabled to avoid hitting
> floating point differences during differential testing (testing the
> interpreter against baseline, against Ion). Enabling SSE2 for all builds
> would remove those differences, which might be beneficial in its own right
> (since content JS running in Ion would no longer behave differently than in
> baseline or the interpreter).
> ___
> 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