Re: [e10s] Higher priority handling for vsync in child processes

[Gabriele Svelto]

On 10/11/2016 18:12, smaug wrote:
> vsync handling happens usually right after a task (per HTML spec).
> Basically we have now two event queues with similar priority, and they
> are handled the same priority, but since
> the other one is used very rarely, events added to it get processed on
> average sooner than the ones added to the normal queue.
> (We can't starve the normal queue, so both need to be processed)
> 
> MemoryPressure seems to want to really processed before any new task, so
> the new system can't be used for that.

Thanks for clearing that up.

> Looks like memory pressure works only on some platforms.

Yes, only on Windows and Android AFAIK, and the former has some serious
issues when it kicks in (which almost never happens BTW, we tend to
OOM-crash well before it does).

 Gabriele



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

Re: Scheduling of async functions

[Boris Zbarsky]

On 11/10/16 7:25 AM, Paolo Amadini wrote:

Is it a deliberate choice that the first chunk of an async function is
executed synchronously instead of waiting for the next microtask?


In terms of implementation or specification?

In terms of implementation, I think it's deliberate in the sense of 
following the spec draft.  Specifically, I believe the call to the async 
function lands at 
https://tc39.github.io/ecmascript-asyncawait/#async-decls-exprs-EvaluateBody 
which calls 
https://tc39.github.io/ecmascript-asyncawait/#abstract-ops-async-function-start 
which in step 5 synchronously "resumes evaluation".


In terms of specification, that's a question for TC39, though afaik they 
modeled their stuff after Task.js to some extent, so that may be where 
the behavior is coming from.



I haven't found any regression test for this in our implementation, and
I guess we should add one either way.


Please file a SpiderMonkey bug?  This should probably be covered in 
test262 as well, if it's not already


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

Re: Adding Rust code to Gecko, now documented

[Boris Zbarsky]

On 11/10/16 4:53 AM, David Teller wrote:

I believe that the only DOM object involved would be Promise


Note that Promise isn't really a DOM object anymore.  It's a 
SpiderMonkey thing.


We still have dom::Promise as a way to create a nice C++-friendly API 
around Spidermonkey Promises.  But nothing forces one to use that...


The general idea of having a thing webidl shim in C++ to make our 
existing bindings work with Rust code is the right one so far, though. 
If it becomes a pain point, we will figure something better out.


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

Usability improvements for Firefox automation initiative - Status update #9

[Armen Zambrano Gasparnian]

On this update we will look at the progress made in the last two weeks.

This quarter’s main focus is on improving end to end times on Try (Thunder
Try project).

Thunder Try - Improve end to end times on try

-

Project #1 - Artifact builds on automation

##

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

Accomplished recently:

   -

   --artifact flag now supports debug builds, except on win32 (see Bug
   1313787)


Project #2 - S3 Cloud Compiler Cache



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

Sccache2 try runs are green and the timing vs the existing sccache look
good.

Upcoming:

   -

   Updating NSS patches today; landing this blocks landing the sccache work


Project #3 - Metrics



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

Accomplished recently:

   -

   Perfherder metrics are now being reported by environment (TaskCluster vs
   Buildbot) and machine type
   -

   More ETL for taskcluster tasks; to match buildbot, and unify the
   wonderful variety of names
   -

   Rough visualization of TC end-to-end times: Required ETL (previous) to
   display better.


Project #4 - Build automation improvements

##

Upcoming:

   -

   TaskCluster Windows builders will soon have >2x CPU capacity and builds
   should become much faster


Project #5 - Hyper chunking

###

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

Nothing relevant at the moment.

Project #6 - Run Web platform tests from the source checkout



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

Waiting on EBS issue to be fixed first.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [e10s] Higher priority handling for vsync in child processes

[Gabriele Svelto]

On 10/11/2016 00:22, smaug wrote:
> Parent process doesn't yet have higher priority handling [2].
> Need to fix racy tests first.
> Locally using higher priority also in parent process seems to make tab
> throbber smoother.

We have an ad-hoc mechanism for scheduling memory pressure event ahead
of all other pending tasks [1]. Do you think we could use this new
functionality to replace it? It would be nice to have this handled via a
generic mechanism too.

 Gabriele

[1]
https://dxr.mozilla.org/mozilla-central/rev/336759fad4621dfcd0a3293840edbed67018accd/xpcom/threads/nsThread.cpp#1444




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

Re: Adding Rust code to Gecko, now documented

[David Teller]

Ok. My usecase is the reimplementation of OS.File in Rust, which should
be pretty straightforward and shave a few Mb of RAM and possibly a few
seconds during some startups. The only difficulty is the actual JS
binding. I believe that the only DOM object involved would be Promise,
I'll see how tricky it is to handle with a combo of Rust and C++.

Thanks,
 David

On 10/11/16 02:43, Bobby Holley wrote:
> On Wed, Nov 9, 2016 at 12:31 PM, David Teller  > wrote:
> 
> \o/
> 
> Do we already have a story for implementing WebIDL in Rust?
> 
> 
> In general, we decided that WebIDL objects need to remain C++, since
> they generally need to interact with the DOM and the extra complexity to
> support pure-Rust objects in Codegen isn't worth it. If there's
> functionality that makes sense to write in Rust, implement the core
> functionality in a Rust crate and just forward to it from the C++ DOM
> object.
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Scheduling of async functions

[Paolo Amadini]

Take the following code example:

  someCondition = false;

  async function onClick(event) {
if (someCondition) {
  await Promise.resolve(); // Or any other async function.
}
event.stopPropagation();
  }

  let called = false;
  onClick({ stopPropagation: () => called = true })
 .catch(console.error);
  console.log("Called:", called);

The callback is called synchronously or not based on someCondition. Is
it a deliberate choice that the first chunk of an async function is
executed synchronously instead of waiting for the next microtask?

This behaves in the same way as the current Task.jsm scheduling, since
we never fixed bug 1030075, but is subject to subtle bugs when used with
callbacks, just like in the example above.

On the other hand, it allows async functions to invoke callbacks for DOM
events, without wrapping them in a normal function. This is handy but
it isn't a good practice anyways, because if the async function throws
an exception it would lead to an unhandled rejection (as if the "catch"
in the example above was missing).

I haven't found any regression test for this in our implementation, and
I guess we should add one either way.

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

Re: Multiple content processes in Nightly

[Gabor Krizsanits]

The patch has been backed out because of the merge. To be continued on next
Monday.
More info about the back-out:
https://bugzilla.mozilla.org/show_bug.cgi?id=1303113#c9

-Gabor

On Thu, Nov 10, 2016 at 1:29 AM, Blake Kaplan  wrote:

> Hello everyone,
>
> We've been working on the e10s-multi project for a while now and are
> looking at turning on multiple content processes in Nightly. Our plan
> is to start with two content processes (compared to the single content
> process we currently use) and if that goes well, we'll start ramping
> up the number of content processes we use as well as playing with more
> exciting process allocation strategies. We are not yet planning to
> ride the trains.
>
> In order to turn on in Nightly, Gabor Krizsanits has been doing a ton
> of work to make sure our tests are green. We've had to disable a
> couple of them in e10s mode and for others we've been forcing them to
> use a single content process (to be clear, the tests themselves are
> broken with multiple content processes and the underlying code is
> not). We will be working on fixing the tests as we can as well as
> turning the disabled tests back on [1].
>
> We have two known bugs that we're enabling with:
>   * Service workers for the same origin can run simultaneously in
> multiple processes [2]. We expect the user-visible aspects of this bug
> to be limited to desktop notifications being duplicated (for each
> content process that has a bogus service worker running in it). bkelly
> is leading a team to fix this.
>
>   * DOM storage doesn't properly propagate changes to other processes
> [3]. This could cause web sites to misbehave. janv is working on
> fixing this.
>
> Let Gabor or me know if you have any concerns or comments and needinfo
> us on bugs that you run into.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1315042
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1231208
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=666724
> --
> Blake
> ___
> 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

Build System Project - Latest Update

[David Burns]

Below is a highlight of all work the build peers have done in the last few
weeks as part of their work to modernise the build infrastructure.

Since the last report[1] a large number of improvements have landed in
Mozilla Central.

The build peers have landed support for a new construct in python configure
(1296530 ) that will,
along upcoming changes, allow simplifications to the python configure code.
It also paves the way for the upcoming pseudo-linter. We have also landed
patches to move some graphics configuration to Python configure (bug 1305145
).

We also investigated parallelising the emitter and backend steps, but found
that our workload is so lopsided to deal with tests, there wasn’t much
parallelism to exploit. Investigating this led to patches to improve this,
resulting in ~⅓ overall improvement landed (bug 1312520
 and bug 1312574
).

The build peers have also spent 2 weeks getting OSX universal builds in
Taskcluster to support ESR through 2018 - bug 1183613
.

Finally, we have also landed patches to build NSS with gyp in the NSS
repository (bug 1237872
). We need to do a
little bit of work to make it work in Mozilla Central but this is tiny task
(dependencies of bug 1295937
).

The NSS work is blocking the SCCache2 work. With the current NSS patches we
are getting green build so expect this work to be complete by the end of
the week.

David

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/2PZnk9mD9Ak/WR9KXZH7BwAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform