Improved timing information for Firefox IPC message profiling now available

[Jim Porter]

Recently, I landed some improvements to IPC profiling support for Firefox:
we're now able to collect timings for each "phase" of an IPC message as it
travels from the sender to its recipient. Now, rather than just recording
the start and end time, we also record when we begin/end sending bytes on
the sender's IO thread, and when we've finished receiving bytes on the
recipient's IO thread. This should help people looking to understand what's
going on with our multiprocessing, since it's now clearer what the
underlying cause of IPC slowness is.

To collect IPC messages with full timings, you'll need to enable IPC
message support in the profiler (about:profiler -> Features -> IPC
Messages), as well as explicitly profiling the IPC IO threads by adding
`Gecko_IOThread` and `Chrome_ChildThread` to the list of threads to be
profiled.

If you'd like more details, screenshots, etc, this feature is documented
here: .

One obvious limitation of this feature at the moment is that it can be
difficult to evaluate the *overall* IPC message performance. In the future,
I plan to provide a better high-level visualization to make this easier. As
always, if you have questions, suggestions, etc, feel free to send me a
message!

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

Firefox Profiler now supports recording IPC messages

[Jim Porter]

Recently, we landed a new feature for the Firefox Profiler: the ability 
to record IPC messages for monitored threads. This should be useful for 
evaluating IPC-related performance issues as we make progress on Project 
Fission. To enable this feature, just check the "IPC Messages" feature 
in the profiler popup and collect a profile! Then, IPC messages on all 
monitored threads will be recorded to the profile.


For an example of what this looks like, see this profile of a user (me) 
opening mozilla.org in a new tab: .


Since IPC messages are (obviously) cross-process, each IPC message is 
actually comprised of two profiler markers: one for the sending thread 
and one for the receiving thread. The profiler frontend then examines 
all the collected IPC markers and correlates the sending and receiving 
sides. After correlating each side, we can then determine the latency of 
the IPC message: this is defined to be the time between when the message 
is sent (i.e. when `SendMessage` or similar is called) and when it's 
received (i.e. once the recipient thread has constructed a `Message` 
object).


Sometimes, IPC messages will have an unknown duration. This means that 
the profiler marker for the other side of the IPC call wasn't recorded 
(either the thread wasn't profiled at all or the other side occurred 
outside of the time range of the profile).


As you can probably see from the example profile, the user interface is 
fairly basic for now: each thread just has a new timeline track to 
display its IPC messages, with outgoing messages in teal and incoming 
messages in purple. Of course, there's lots of room for improvement 
here, so if you have ideas for a visualization that would be useful to 
you, just file a bug and CC me on it!


Happy profiling!
- Jim

P.S.: For those who are curious about how we correlate each side of an 
IPC message, we compare the source and destination PIDs, the message's 
type, and its seqno. This is enough to uniquely identify any IPC 
message, though it does mean that reply messages are considered a 
separate message. If people find it useful, it should be straightforward 
to correlate initial and reply messages with each other as well.

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

Re: How are events passed between chrome and content?

[Jim Porter]

On 6/16/17 6:18 AM, smaug wrote:
> On 06/16/2017 02:32 AM, Jim Porter wrote:
>> Here's the code I'm currently using to generate a contextmenu event:
>> <https://github.com/jimporter/gesticulate/blob/e10s/src/chrome/modules/mouseGestures.jsm#L214-L216>.
>>
> That just dispatches the event to dom. No forwarding to child process
> will happen.
> You need to use methods in nsIDOMWindowUtils to dispatch events in a way
> which simulates real events better
> and causes forwarding to happen.

Awesome, it works! Thanks for the pointer.

Now I just need to work on making this into a WebExtension... :)

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

Re: How are events passed between chrome and content?

[Jim Porter]

On 6/15/17 4:12 PM, Kartikaya Gupta wrote:
> Not quite. For e10s, mouse events are sent across the process boundary
> using the PBrowser ipdl protocol. On the parent side they go into
> EventStateManager::DispatchCrossProcessEvent [1] which picks up the
> TabParent and sends it over IPC to the TabChild. The TabChild then
> dispatches it to the PuppetWidget in the content process.

Thanks for the code reference! That at least gives me a rough idea of
where all this is happening so I can maybe debug it.

> If you set the right flags on the event it should get through.
> Presumably you're creating this event from JS - you want to make sure
> that it creates a WidgetMouseEvent with eContextMenu message type. I
> don't know if that can be done without using the DOMWindowUtils APIs.
> Posting your code snippet for event creation might help.

Here's the code I'm currently using to generate a contextmenu event:
.
As mentioned, it works fine for creating a context menu in chrome, but
not content. (It also works fine in non-e10s content, but that shouldn't
be surprising.) I might be missing something, but when I looked in the
inspector, I didn't see any obvious differences between this event and
the original contextmenu event that I suppressed.

Maybe there's some issue with the event target? When the original
contextmenu event is fired, it says the target is the XUL tabbrowser
(#content) and the originalTarget is the XUL browser element. I've tried
dispatching my synthetic event to both, but neither does anything.

I've also tried keeping the original contextmenu event around that I
suppressed and re-dispatching that, but it doesn't work either. However,
since I called .preventDefault()/.stopPropagation() on that object, I'm
not sure I'd expect it to work anyway.

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

How are events passed between chrome and content?

[Jim Porter]

>From what I can tell, if I click inside a webpage, the event starts out
in chrome and then propagates down into content. I assume there's some
sort of magic happening in the message manager that pushes the event
across process boundaries. However, I can't figure out how to create my
own event in chrome and have it propagate down into content. Is there
any code/documentation I should be looking at to figure out how to do this?

If you're wondering why I want to know about this, read on; otherwise,
you can stop here.

I'm working on a Firefox add-on for mouse gestures and as part of this I
need to delay the opening of the context menu on Linux to occur on
mouseup rather than mousedown. I do this by swallowing the original
contextmenu event with .preventDefault()/.stopPropagation(). Then on
mouseup, I synthesize my own contextmenu event. This works fine when
clicking on something in chrome, but no context menu pops up if I click
on something in content.

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

Re: Nuwa on desktop

[Jim Porter]

On 04/07/2015 06:06 PM, Robert O'Callahan wrote:
 On Wed, Apr 8, 2015 at 8:00 AM, andreas@gmail.com wrote:
 Not sure do what degree we can replicate on Windows what we do on 
 FFOS to launch content processes.
 
 The Cygwin people have looked into fork() in Windows a bit. Some 
 links: 
 http://www.cygwin.com/ml/cygwin-developers/2011-04/msg00036.html 
 https://github.com/kaniini/win32-fork/blob/master/fork.c It doesn't 
 look promising. Maybe if would work if we ever get to the point
 where a content process doesn't need to use any Win32 APIs.

Even if you used something like Cygwin's fork(), it wouldn't help you,
since their implementation isn't copy-on-write:

  Currently, the Cygwin fork is a non-copy-on-write implementation
  similar to what was present in early flavors of UNIX.[1]

As far as I know, it's flat-out *impossible* to implement copy-on-write
process creation using the Win32 API (and if it's not actually
impossible, it's pretty close). The NT API is another story, but unless
you want to use Windows Services for UNIX / Interix, you're probably not
going to get access to the NT kernel features you'd need to do it.

 We might be able to do something Nuwa-like where Gecko subsystems
 use an explicit shared data segment which is a copy-on-write view of
 a file.

I agree. Shared memory (e.g. CreateFileMapping[2]?) seems like the
closest thing on Windows, although that's a part of the Win32 API I've
never touched.

- Jim

[1] http://www.cygwin.com/cygwin-ug-net/highlights.html
[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366539%28v=vs.85%29.aspx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is anyone still using JS strict warnings?

[Jim Porter]

On 12/19/2014 02:19 PM, Jason Orendorff wrote:
 So if you go to about:config and set the javascript.options.strict pref,
 you'll get warnings about accessing undefined properties.
 
 Please speak up now, if you're still using it!

I find these warnings quite useful (granted, I'm the sort of person who
compiles C++ with `-Wall -Wextra -Werror -pedantic`), and I've often
wished that I could make these errors show up at compile/lint time in
Firefox OS.

In particular, I really like seeing warnings about accessing undefined
properties when I'm refactoring code or changing an API. It's easy to
forget to change a single instance of a property when refactoring, and
having a warning at least gets me partway to being able to verify that I
did things correctly. (Tests help too, of course, but even a good test
suite probably won't catch *every* possible bug.)

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

Re: Deprecating localstore.rdf

[Jim Porter]

On 07/23/2014 07:10 AM, rviti...@mozilla.com wrote:
 Are there any objections or remarks to the deprecation of
 localstore.rdf?

Just to be proactive, is there anything that other applications (read:
Thunderbird) will need to do about this, or will it just automatically work?

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

Re: Proposal for adding named arguments to C++

[Jim Porter]

On 06/15/2014 05:04 AM, Botond Ballo wrote:
 I would love to get more people at Mozilla involved in C++
 standardization / get more organized about it.
 
 I also have a standing offer to assist anyone at Mozilla who would
 like to write a standards proposal do so, and present the proposal
 at a committee meeting if they are not able to attend. If you have
 some proposals in mind, let me know :)

If you're interested, I started some discussion[1] about making C arrays
have more value semantics in C++ (most especially copyability). This is
important to me because I'd like to be able to do something like
lambda's capture-by-copy, only in a class, e.g.:

  SomeType cap; // SomeType could be an object or an array.

  [cap]() { /* ... */ }; // Always works

  templatetypename T
  struct capture {
foo(const T t) : data(t) {}
T data;
/* ... */
  };
  fooSomeType f(cap); // Fails if SomeType is an array

I'm not sure there's any immediate need for this at Mozilla, but it's
something that would simplify generic programming a bit. C arrays have
some weird semantics, and unfortunately, std::array is only a partial fix.

- Jim

[1]
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-discussion/JrqQBUyrGU4

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

Re: Proposal for adding named arguments to C++

[Jim Porter]

On 06/14/2014 01:07 PM, Botond Ballo wrote:
 Ehsan and I would like to propose named arguments as a new feature for C++.

A bit off-topic, but do we at Mozilla have any kind of a (semi-)
organized group of folks involved with C++ standardization? I follow
along fairly closely (especially in SG7 - Reflection) and have a couple
of proposals I'm thinking about, but that's strictly in my spare time.
It'd be nice to have some Mozilla connections for this as well.

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

Re: Mozilla style guide issues, from a JS point of view

[Jim Porter]

On 01/06/2014 08:23 PM, Karl Tomlinson wrote:

Yes, those are the sensible options.

Wrapping at  80 columns just makes things worse for those that
like to save some screen room for something else, view code on a
mobile device, etc.


I for one prefer wrapping at 80 columns because with my font settings, I 
can have 3 buffers open side-by-side. I generally find that a lot more 
useful than the vertical space that would be saved by wrapping at, say, 
100 columns.


- Jim

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

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

[Jim Porter]

On 10/10/2013 11:22 AM, Botond Ballo wrote:

Is there any interest in having Mozilla be officially represented at the
C++ Standards Committee?


I actually asked about this a couple months ago (with the goal of being 
one of the representatives). I'm glad to see there's some more traction 
on this, since I think it's pretty important for us to be involved with 
the C++ standardization process. I'm also still happy to help out by 
working with the standards committee, assuming 1) this is something 
Mozilla chooses to do, and 2) there's space for me to join in.


- Jim

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

Re: What platform features can we kill?

[Jim Porter]

On 10/09/2013 12:37 PM, Chris Peterson wrote:

On 10/9/13 9:49 AM, Benjamin Smedberg wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF

I'm all for this, although the risk is probably quite small because we
don't expose RDF to content.


Bug 833098 - Kick RDF out of Firefox

Comments in the bug suggest a build-time flag because Thunderbird needs
on RDF.


Thunderbird doesn't really want RDF either. However, killing RDF in 
Thunderbird has been a slow process. If there's anyone who wants to help 
kill RDF in Thunderbird, go for it!


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

Re: Easiest way to start using httpd.js?

[Jim Porter]

On 10/17/2012 06:27 PM, Gregory Szorc wrote:

Let me know if you have any questions.


I have a followup question: is there an easy way to use https with 
httpd.js? ActiveSync Autodiscovery requires https. (I don't absolutely 
need to test Autodiscovery though, so if I can't do this, it's not the 
end of the world.)


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