It is now possible[1] to create chrome-only WebIDL interfaces in
the dom/chrome-webidl/ directory that do not require review by
DOM peers after every change. If you maintain an internal
performance-sensitive XPIDL interface, or are considering
creating one, I'd encourage you to consider migrating it to
WebIDL.

Some caveats to keep in mind:

- Interfaces in this directory must be annotated with
[ChromeOnly]. Dictionaries, however, can be included without any
special annotations.

- If you are new to writing WebIDL files, I'd still encourage
you to ask a DOM peer to review at least your initial check-in.

- Please make sure that you do not attempt to expose any of the
interface or dictionary types defined in these WebIDL files to
web contexts, through interfaces defined in dom/webidl/. Doing so
would require (and fail) DOM peer review, in any case, but
please think ahead.

Thanks.

- Kris

[1]: As of bugs 1443317 and 1442931

I've seen a lot of momentum around migrating chrome-only XPIDL interfaces
to WebIDL. I'm concerned that insufficient attention is being paid to the
impact on our binary size.

Fundamentally, the WebIDL bindings improve performance and spec correctness
at the expense of code size (and build times). This makes sense for things
that are web-exposed or performance-sensitive. But since the webidl
bindings are also more modern and easier to use, I'm concerned that people
will use them indiscriminately for all sorts of internal APIs, and our
binary will bloat by a thousand paper cuts.

A WebIDL method binding can easily cost a kilobyte or more, depending on
the number and types of the arguments. If we were to convert all of our
existing xpidl methods, we could approach 10MB in added code size.

Gating on DOM peer review gave us some degree of oversight to prevent
overuse. What should replace it?
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote:
>I've seen a lot of momentum around migrating chrome-only XPIDL interfaces
>to WebIDL. I'm concerned that insufficient attention is being paid to the
>impact on our binary size.
>
>Fundamentally, the WebIDL bindings improve performance and spec correctness
>at the expense of code size (and build times). This makes sense for things
>that are web-exposed or performance-sensitive. But since the webidl
>bindings are also more modern and easier to use, I'm concerned that people
>will use them indiscriminately for all sorts of internal APIs, and our
>binary will bloat by a thousand paper cuts.
>
>A WebIDL method binding can easily cost a kilobyte or more, depending on
>the number and types of the arguments. If we were to convert all of our
>existing xpidl methods, we could approach 10MB in added code size.

I'm not sure how much of an immediate concern this should be.

There are different costs to WebIDL and XPIDL bindings. WebIDL
bindings have more cost in terms of compiled code size. XPIDL
have greater costs in terms of performance and runtime memory.
I'm not sure exactly where the balance is as far as impact to
package size.

And I think the benefits of WebIDL interfaces apply as much to
our internal uses as they do to web-exposed interfaces. The
amount of WebIDL overhead I regularly see in profiles can be
staggering. And XPIDL has enough foot-guns when interfacing with
JS that it's easy enough cause confusion and breakage even when
dealing with internal code.

That said, if we're worried about binary size becoming an issue
for internal interfaces, there are things we can do to reduce
the code size of bindings. Particularly if we're willing to eat
the performance costs.

At any rate, I don't expect us to convert anywhere near all of
our XPIDL interfaces to WebIDL. A lot of them don't need to be
exposed to JS at all. A lot of those should still go away, but
they don't need WebIDL bindings, just concrete native classes.
And a lot of the rest are little-enough used that I can't see
anyone spending the effort on converting them.

>Gating on DOM peer review gave us some degree of oversight to prevent
>overuse. What should replace it?

How much have DOM peers been focusing on preventing over-use, so
far? Granted, most of the WebIDL bindings I've created to date
have been to address measurable performance issues, but I've
never had a reviewer suggest that I should be worried about
over-use.

On Thu, Mar 08, 2018 at 03:06:57PM -0800, Kris Maglione wrote:
>The amount of WebIDL overhead I regularly see in profiles can
>be staggering.

The amount of *XPConnect* overhead...

Generally I think we’d take performance and memory wins over installer
size, but we monitor all three and if installer size grows (gradually) by
an uncomfortable amount we ought to make a call on the trade off. We can
bring it to product should that happen.

On Thu, Mar 8, 2018 at 6:07 PM Kris Maglione <kmag...@mozilla.com> wrote:

> On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote:
> >I've seen a lot of momentum around migrating chrome-only XPIDL interfaces
> >to WebIDL. I'm concerned that insufficient attention is being paid to the
> >impact on our binary size.
> >
> >Fundamentally, the WebIDL bindings improve performance and spec
> correctness
> >at the expense of code size (and build times). This makes sense for things
> >that are web-exposed or performance-sensitive. But since the webidl
> >bindings are also more modern and easier to use, I'm concerned that people
> >will use them indiscriminately for all sorts of internal APIs, and our
> >binary will bloat by a thousand paper cuts.
> >
> >A WebIDL method binding can easily cost a kilobyte or more, depending on
> >the number and types of the arguments. If we were to convert all of our
> >existing xpidl methods, we could approach 10MB in added code size.
>
> I'm not sure how much of an immediate concern this should be.
>
> There are different costs to WebIDL and XPIDL bindings. WebIDL
> bindings have more cost in terms of compiled code size. XPIDL
> have greater costs in terms of performance and runtime memory.
> I'm not sure exactly where the balance is as far as impact to
> package size.
>
> And I think the benefits of WebIDL interfaces apply as much to

> our internal uses as they do to web-exposed interfaces. The

> amount of WebIDL overhead I regularly see in profiles can be

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

> Kris Maglione <mailto:kmag...@mozilla.com>
> 2018 March 8 at 15:06

> At any rate, I don't expect us to convert anywhere near all of our
> XPIDL interfaces to WebIDL. A lot of them don't need to be exposed to
> JS at all. A lot of those should still go away, but they don't need
> WebIDL bindings, just concrete native classes. And a lot of the rest
> are little-enough used that I can't see anyone spending the effort on
> converting them.

Would that remain true if doing so would enable us to remove XPCOM entirely?

-myk

Removing XPCOM entirely is not really a possibility. Removing XPConnect
bindings entirely is... theoretically possible, but would be a monumental
amount of work, and is not something I've heard anyone seriously suggest.

Even if we were to consider going that route, I think we'd wind up writing a
more restricted set of JS bindings for a lot of the things we wanted to
continue exposing, rather than converting the existing bindings to WebIDL.

My point is that the cost of WebIDL bindings scales with the number of
methods in the tree, whereas the cost of XPIDL bindings scale with usage.
I'm totally supportive of moving frequently-called methods to WebIDL. But
there's an enormous surface of rarely-used XPIDL APIs in our tree where the
tradeoffs don't make sense (over five thousand methods, and several
thousand more attributes). We generally need these APIs for something or
other - devtools, tests, some infrequent or one-time browser operation, etc
- but a few extra microseconds of call overhead is fine.

> That said, if we're worried about binary size becoming an issue for
> internal interfaces, there are things we can do to reduce the code size of
> bindings. Particularly if we're willing to eat the performance costs.
>

WebIDL bindings are optimized for speed above all else, and that shouldn't
have to change to mitigate overuse.

> At any rate, I don't expect us to convert anywhere near all of our XPIDL
> interfaces to WebIDL. A lot of them don't need to be exposed to JS at all.
> A lot of those should still go away, but they don't need WebIDL bindings,
> just concrete native classes. And a lot of the rest are little-enough used
> that I can't see anyone spending the effort on converting them.

I am basically worried about two things:
(1) Wholescale conversions of big interfaces in the name of cleanup and
ergonomics. See bug 1341546 for an example.
(2) People sticking new non-performance-critical things on WebIDL
interfaces because that's where the other (possibly-performance-critical)
code lives.

> Gating on DOM peer review gave us some degree of oversight to prevent
>> overuse. What should replace it?
>>
>
> How much have DOM peers been focusing on preventing over-use, so far?
> Granted, most of the WebIDL bindings I've created to date have been to
> address measurable performance issues, but I've never had a reviewer
> suggest that I should be worried about over-use.

It hasn't been a concern because WebIDL has mostly been used for
web-exposed interfaces, and the momentum to convert internal interfaces is
a relatively recent trend. FWIW, I did plan to bring it up at the next DOM
peer meeting.

I'm not entirely sure whether a review gate is necessary. But at the very
least, I want to establish a consensus around that we should only use
WebIDL to expose internal interfaces if one of the following applies:
(A) The API is likely to be called hundreds of times under normal browser
execution.
(B) The API is associated with a DOM object, and thus adding it
[ChromeOnly] to that interface is particularly convenient.
(C) The API uses complex arguments like promises that XPIDL doesn't handle
in a nice way.

Opinions?

On Thu, Mar 8, 2018 at 3:16 PM, Stuart Philp <sph...@mozilla.com> wrote:

> Generally I think we’d take performance and memory wins over installer
> size, but we monitor all three and if installer size grows (gradually) by
> an uncomfortable amount we ought to make a call on the trade off. We can
> bring it to product should that happen.
>

The problem is precisely that it's gradual - a few kilobytes at a time,
certainly nothing to trigger our alerts. Waiting for it all to pile up and
then launching a herculean effort to move things _back_ to XPIDL would be a
huge waste of time, which is why I'm trying to address the problem now.

On Thu, Mar 08, 2018 at 11:16:44PM +0000, Stuart Philp wrote:
> Generally I think we’d take performance and memory wins over installer
> size, but we monitor all three and if installer size grows (gradually) by
> an uncomfortable amount we ought to make a call on the trade off. We can
> bring it to product should that happen.

Note that bigger binary sizes means more memory usage mechanically.

Mike

On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote:
> I've seen a lot of momentum around migrating chrome-only XPIDL interfaces
> to WebIDL. I'm concerned that insufficient attention is being paid to the
> impact on our binary size.
>
> Fundamentally, the WebIDL bindings improve performance and spec correctness
> at the expense of code size (and build times). This makes sense for things
> that are web-exposed or performance-sensitive. But since the webidl
> bindings are also more modern and easier to use, I'm concerned that people
> will use them indiscriminately for all sorts of internal APIs, and our
> binary will bloat by a thousand paper cuts.
>
> A WebIDL method binding can easily cost a kilobyte or more, depending on
> the number and types of the arguments. If we were to convert all of our
> existing xpidl methods, we could approach 10MB in added code size.

Last time I looked at bindings, I was horrified to see all the various
strings that all look the same except between bindings for field and
class names. I wonder how much of the bindings cost in terms of binary
size is due to that, or other similar inefficiencies. At least there
seems to be a low hanging fruit there. (IIRC, the same was true of ipdl
bindings)

Mike

I was just measuring the methods themselves via |nm --print-size|. There
might be additional per-method overhead in the data segment for the
associated static tables, but the baseline size for the code itself
(argument conversion, error handling, etc) is nontrivial.


>
> Mike
>

On Fri, Mar 9, 2018, at 8:41 AM, Bobby Holley wrote:
> The problem is precisely that it's gradual - a few kilobytes at a
> time, certainly nothing to trigger our alerts. Waiting for it all to
> pile up and then launching a herculean effort to move things _back_ to
> XPIDL would be a huge waste of time, which is why I'm trying to
> address the problem now.

How much effort would it be, and would it be worth it, to support Web
IDL argument conversion in a more dynamic way, like XPConnect does,
and then opt in to this for interfaces / methods we decide are not
performance critical?  (I'm guessing that it would be a fair amount
of effort.)

On Fri, Mar 9, 2018 at 2:26 PM, Bobby Holley <bobby...@gmail.com> wrote:

> I was just measuring the methods themselves via |nm --print-size|. There
> might be additional per-method overhead in the data segment for the
> associated static tables, but the baseline size for the code itself
> (argument conversion, error handling, etc) is nontrivial.
>

It might be worth measuring how that translates to installer code. One
might hope that all that repetitive boilerplate code compresses well (or
can be made to).

Rob
--
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.

On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote:
>On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione <kmag...@mozilla.com> wrote:
>> That said, if we're worried about binary size becoming an issue for
>> internal interfaces, there are things we can do to reduce the code size of
>> bindings. Particularly if we're willing to eat the performance costs.
>
>WebIDL bindings are optimized for speed above all else, and that shouldn't
>have to change to mitigate overuse.

My point is that if we're deciding that we need to make a trade-off between
speed and compiled binary size, I think that we're better off doing that by
changing how we generate the bindings for interfaces that we decide are not
performance sensitive than deciding to use XPIDL for them. If nothing else, it
makes it easier for us to make the change for a particular interface, or to
change our mind.

>> At any rate, I don't expect us to convert anywhere near all of our XPIDL
>> interfaces to WebIDL. A lot of them don't need to be exposed to JS at all.
>> A lot of those should still go away, but they don't need WebIDL bindings,
>> just concrete native classes. And a lot of the rest are little-enough used
>> that I can't see anyone spending the effort on converting them.
>
>
>I am basically worried about two things:
>(1) Wholescale conversions of big interfaces in the name of cleanup and
>ergonomics. See bug 1341546 for an example.

Heh. It's interesting that you bring that interface up, because I've been
thinking for a long time that it's one of the most obvious examples of
something we should convert to WebIDL. We use it all over the place, and it's
one of the places that I see XPConnect overhead turn up most for in profiles.

>I'm not entirely sure whether a review gate is necessary. But at the very
>least, I want to establish a consensus around that we should only use
>WebIDL to expose internal interfaces if one of the following applies:
>(A) The API is likely to be called hundreds of times under normal browser
>execution.
>(B) The API is associated with a DOM object, and thus adding it
>[ChromeOnly] to that interface is particularly convenient.
>(C) The API uses complex arguments like promises that XPIDL doesn't handle
>in a nice way.
>
>Opinions?

I don't really have a problem with these criteria. That's more or less what I
consider when deciding how to implement bindings.

But I'd really rather we didn't have to make this trade-off. There's no
fundamental reason WebIDL bindings have to have more code size overhead than
XPIDL bindings. The implementation details are almost completely separated
from the consumers, and if at some point we decide the overhead is becoming a
problem and we need to make a trade-off, we can always change the
implementation that we use for interfaces we think are not performance
critical.

>On Thu, Mar 8, 2018 at 3:16 PM, Stuart Philp <sph...@mozilla.com> wrote:
>
>> Generally I think we’d take performance and memory wins over installer
>> size, but we monitor all three and if installer size grows (gradually) by
>> an uncomfortable amount we ought to make a call on the trade off. We can
>> bring it to product should that happen.
>>
>

>The problem is precisely that it's gradual - a few kilobytes at a time,
>certainly nothing to trigger our alerts. Waiting for it all to pile up and
>then launching a herculean effort to move things _back_ to XPIDL would be a
>huge waste of time, which is why I'm trying to address the problem now.
>
>

>> On Thu, Mar 8, 2018 at 2:01 PM, Kris Maglione <kmag...@mozilla.com>
>>> wrote:
>>>
>>> It is now possible[1] to create chrome-only WebIDL interfaces in the
>>>> dom/chrome-webidl/ directory that do not require review by DOM peers
>>>> after
>>>> every change. If you maintain an internal performance-sensitive XPIDL
>>>> interface, or are considering creating one, I'd encourage you to consider
>>>> migrating it to WebIDL.
>>>>
>>>> Some caveats to keep in mind:
>>>>
>>>> - Interfaces in this directory must be annotated with [ChromeOnly].
>>>> Dictionaries, however, can be included without any special annotations.
>>>>
>>>> - If you are new to writing WebIDL files, I'd still encourage you to ask
>>>> a
>>>> DOM peer to review at least your initial check-in.
>>>>
>>>> - Please make sure that you do not attempt to expose any of the interface
>>>> or dictionary types defined in these WebIDL files to web contexts,
>>>> through
>>>> interfaces defined in dom/webidl/. Doing so would require (and fail) DOM
>>>> peer review, in any case, but please think ahead.
>>>>
>>>> Thanks.
>>>>
>>>> - Kris
>>>>
>>>> [1]: As of bugs 1443317 and 1442931
>>>>
>>>

--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

It is practically impossible to teach good programming style to
students that have had prior exposure to Basic; as potential
programmers they are mentally mutilated beyond hope of regeneration.
        --Edsger W. Dijkstra

On Thu, Mar 8, 2018 at 5:56 PM, Kris Maglione <kmag...@mozilla.com> wrote:

> On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote:
>
>> On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione <kmag...@mozilla.com>
>> wrote:
>>
>>> That said, if we're worried about binary size becoming an issue for
>>> internal interfaces, there are things we can do to reduce the code size
>>> of
>>> bindings. Particularly if we're willing to eat the performance costs.
>>>
>>
>> WebIDL bindings are optimized for speed above all else, and that shouldn't
>> have to change to mitigate overuse.
>>
>
> My point is that if we're deciding that we need to make a trade-off
> between speed and compiled binary size, I think that we're better off doing
> that by changing how we generate the bindings for interfaces that we decide
> are not performance sensitive than deciding to use XPIDL for them. If
> nothing else, it makes it easier for us to make the change for a particular
> interface, or to change our mind.
>

To be sure I understand: you're proposing what Cameron proposed, which is
to support two separate modes in the WebIDL bindings ("fast" and
"compact")? And the "compact" mode would use general hooks and interpret
arguments on-the-fly like XPConnect does?

Doing so would be an enormous amount of work (measured in engineer-years),
and the result would likely have lots of bugs in the corner cases. Asking
people to be thoughtful about their usage of WebIDL vs XPIDL is much more
attractive.

At any rate, I don't expect us to convert anywhere near all of our XPIDL
>>> interfaces to WebIDL. A lot of them don't need to be exposed to JS at
>>> all.
>>> A lot of those should still go away, but they don't need WebIDL bindings,
>>> just concrete native classes. And a lot of the rest are little-enough
>>> used
>>> that I can't see anyone spending the effort on converting them.
>>>
>>
>>
>> I am basically worried about two things:
>> (1) Wholescale conversions of big interfaces in the name of cleanup and
>> ergonomics. See bug 1341546 for an example.
>>
>
> Heh. It's interesting that you bring that interface up, because I've been
> thinking for a long time that it's one of the most obvious examples of
> something we should convert to WebIDL. We use it all over the place, and
> it's one of the places that I see XPConnect overhead turn up most for in
> profiles.
>

I just looked at the first 10 methods/attributes on that interface. None of
them are remotely performance-sensitive, and several are test-only. If we
see certain methods on it show up in profiles, we should move those methods
to WebIDL, rather than converting things wholesale per-interface.

>
> I'm not entirely sure whether a review gate is necessary. But at the very
>> least, I want to establish a consensus around that we should only use
>> WebIDL to expose internal interfaces if one of the following applies:
>> (A) The API is likely to be called hundreds of times under normal browser
>> execution.
>> (B) The API is associated with a DOM object, and thus adding it
>> [ChromeOnly] to that interface is particularly convenient.
>> (C) The API uses complex arguments like promises that XPIDL doesn't handle
>> in a nice way.
>>
>> Opinions?
>>
>
> I don't really have a problem with these criteria. That's more or less
> what I consider when deciding how to implement bindings.
>
> But I'd really rather we didn't have to make this trade-off. There's no
> fundamental reason WebIDL bindings have to have more code size overhead
> than XPIDL bindings.

There totally is.

There are basically two ways to do JS<->C++ bindings: generating explicit
stubs for each method, or using a single generic stub with compact type
information to convert things on the fly.

Gecko originally did the former (MIDL). For various reasons (including code
size), we then we switched everything to the latter (XPConnect/XPIDL). But
the latter ran into two problems, which caused us to flip-flop and
reimplement a codegen setup for the DOM:
(A) Doing everything on-the-fly was really slow.
(B) It was increasingly difficult to properly handle the complex and
expressive types making their way into WebIDL.

So even if we didn't care about (A), and even if we were willing to spend
the time to make an XPConnect-like backend for WebIDL, we'd run straight
into the same problems trying to support the trickier bits of WebIDL.

The implementation details are almost completely separated from the
> consumers, and if at some point we decide the overhead is becoming a
> problem and we need to make a trade-off, we can always change the
> implementation that we use for interfaces we think are not performance
> critical.

The WebIDL codegen bindings took years for a number of our best engineers
to build. I don't see a case here for taking on more work of that magnitude
when the alternative is so straightforward.

On Fri, Mar 9, 2018, at 9:41 AM, Robert O'Callahan wrote:
> It might be worth measuring how that translates to installer code. One
> might hope that all that repetitive boilerplate code compresses well
> (or can be made to).

Testing my local bug 1341546 patches, I get a 59 KiB increase in
.tar.bz2 package size and 189 KiB increase in libxul.so, which does seem
a bit much for the ergonomic gains I was going for.

On 3/8/18 8:04 PM, Mike Hommey wrote:
> Last time I looked at bindings, I was horrified to see all the various
> strings that all look the same except between bindings for field and
> class names.

So for what it's worth, I tried measuring this recently.  When measuring
with "size" on Mac, if I just made all such strings "" I saved something
like dozens of KB, if I recall correctly.

> I wonder how much of the bindings cost in terms of binary
> size is due to that, or other similar inefficiencies. At least there
> seems to be a low hanging fruit there.

I expect there is, but it wasn't super-obvious low-hanging fruit.  I did
some other experiments as well.  If I just cut out the bodies of all the
"specialized methods" (getters, setters, operations), that saved about
4.5MB of codesize.  That's basically the actual generated code of all of
those, but not including the data tables we use to set up the
prototypes, the various union/dictionary stuff, etc.  That 4.5MB was
about evenly split between getters, setters, and operations.

I had also spent some time trying to un-inline some things.  Typically
the codesize went _up_ when I did that for bindings stuff...  At least
on x86-64, the size overhead of a function call was bigger than the work
those functions did.

It's possible that I made mistakes when making those measurements, of
course.

The other relevant data point is that iirc I measured about 8800
getters/setters/operations.  So they're averaging about 500 bytes each.
I don't know how big the xptinfo is for a single xpidl method.  I also
don't know how well these various bits share across processes.  And
there's some memory usage (in those data tables I mentioned) even
outside the code of the webidl methods.

-Boris

On 3/8/18 11:29 PM, Boris Zbarsky wrote:
> I expect there is, but it wasn't super-obvious low-hanging fruit.

Sorry, I should have been clearer: there wasn't super-obvious
low-hanging fruit in the getter/setter/method bits.  At least the parts
of it I poked at.

There might also be low-hanging fruit in the per-binding (as opposed to
per-member) overhead.  Adrian (the patch author on bug 1297480) was
pointing out that we could pack PropertyInfo structs to save about 150KB
on 65-bit, at the cost of ending up with unaligned reads.  I don't know
how viable that is on ARM64.

Adrian also pointed out that
GetConstructorObjectHandle/GetProtoObjectHandle might be able to be
commoned up some and save some per-binding codesize.  I just filed bug
1444286 on this and will do some measurements.

There might also be other things there.

-Boris

On Fri, Mar 9, 2018 at 1:16 AM, Stuart Philp <sph...@mozilla.com> wrote:
> Generally I think we’d take performance and memory wins over installer
> size, but we monitor all three and if installer size grows (gradually) by
> an uncomfortable amount we ought to make a call on the trade off. We can
> bring it to product should that happen.

"Installer" implies Windows.

I think the thing we should have learned from the multi-year
ICU-on-Android situation is that having Gecko development blocked by a
binary size concern from product is such a bad situation to be in that
we should avoid getting into that situation rather expect to be able
to take corrective action if we get into that situation.

(A key reason why encoding_rs is smaller than uconv despite offering
more functionality is that not getting it blocked on binary size
grounds was a design priority before writing code.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley <bobby...@gmail.com> wrote:

> I just looked at the first 10 methods/attributes on that interface. None
> of them are remotely performance-sensitive, and several are test-only. If
> we see certain methods on it show up in profiles, we should move those
> methods to WebIDL, rather than converting things wholesale per-interface.
>
>

Are you suggesting that we build two IDLs per interface - one for
perfomance-bound methods and the other for "non-performance-critical" ones?

I'm just a used of XPIDL/WebIDL but I noticed that almost every interface I
build or use has a mixture of those two types.

>From that perspective, ability to write a single IDL file and mark which
functions should be perf-critical (or the opposite) would be significantly
better UX and more fine-tunable over time.

But if your recommendation is to go for two, I would really appreciate a
tutorial explaining how to design a C++ and JS API with those two IDLs
separating perf-critical methods from others.

zb.
p.s. I understand your concern about sinking time into developing a WebIDL
for XPIDL replacement. At the same time, my understanding is that no matter
how much time something took in the past, we (in general) design our
architecture for a much longer future. So if we can introduce something
soon that will allow all new APIs to benefit from it, the argument of how
many APIs we already have that use the old model is diminishing.

On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
> (C) The API uses complex arguments like promises that XPIDL doesn't handle
> in a nice way.

I think this is an understated point. WebIDL was designed explicitly to allow expressing the semantics of JS APIs, where XPIDL is some arbitrary set of things designed by folks at Netscape a long time ago. Almost any non-trivial API will wind up being worse in XPIDL (and the C++ implementation side is worse as well).

I agree that an XPConnect-alike supporting WebIDL semantics would be a lot of work, but I also think that asking developers to implement chrome interfaces with XPIDL is pretty lousy.

-Ted

On 09/03/2018 00:06, Kris Maglione wrote:
> There are different costs to WebIDL and XPIDL bindings. WebIDL bindings
> have more cost in terms of compiled code size. XPIDL have greater costs
> in terms of performance and runtime memory.

It's not that simple. In terms of runtime memory for example, XPIDL also
has *different* costs than WebIDL (which requires a nsWrapperCache and
CC integration). Depending on usage those might be greater or smaller.

> How much have DOM peers been focusing on preventing over-use, so far?
> Granted, most of the WebIDL bindings I've created to date have been to
> address measurable performance issues, but I've never had a reviewer
> suggest that I should be worried about over-use.

I've certainly started to worry about it recently. I know you focused on
performance sensitive interfaces specifically in your message (and in
your patches), but I worry that that message will get lost over time. We
really need to emphasize that there's a difference in cost. And there
are fundamental differences between the two models that cause that.

That said, we should continue looking into reducing the cost of WebIDL
in terms of binary size (and we are).

Peter

On Fri, Mar 9, 2018 at 12:15 AM, Zibi Braniecki (Gandalf) <
zbran...@mozilla.com> wrote:

>
>
> On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley <bobby...@gmail.com>
> wrote:
>
>> I just looked at the first 10 methods/attributes on that interface. None
>> of them are remotely performance-sensitive, and several are test-only. If
>> we see certain methods on it show up in profiles, we should move those
>> methods to WebIDL, rather than converting things wholesale per-interface.
>>
>>
>
> Are you suggesting that we build two IDLs per interface - one for
> perfomance-bound methods and the other for "non-performance-critical" ones?
>

People should default to XPIDL for internal interfaces unless they have a
compelling reason to do otherwise.
* If that reason is a frequently-invoked method, they should consider:
** Whether it needs to be invoked so frequently - could it batch instead,
or expose a different abstraction?
** Whether it really needs its own interface - could we just stick it on
ChromeUtils?
* If that reason is complex types, they should consider whether the API
actually needs to be so fancy.

If the reasons hold water, creating a new ChromeOnly WebIDL interface is
fine. Sticking a handful of ridealongs on the interface is probably also
ok, but we should be mindful of the quantity and cost, and consider
reshuffling if they pile up.

I'm just a used of XPIDL/WebIDL but I noticed that almost every interface I
> build or use has a mixture of those two types.
>
> From that perspective, ability to write a single IDL file and mark which
> functions should be perf-critical (or the opposite) would be significantly
> better UX and more fine-tunable over time.
>
> But if your recommendation is to go for two, I would really appreciate a
> tutorial explaining how to design a C++ and JS API with those two IDLs
> separating perf-critical methods from others.
>
> zb.
> p.s. I understand your concern about sinking time into developing a WebIDL
> for XPIDL replacement. At the same time, my understanding is that no matter
> how much time something took in the past, we (in general) design our
> architecture for a much longer future. So if we can introduce something
> soon that will allow all new APIs to benefit from it, the argument of how
> many APIs we already have that use the old model is diminishing.
>

My argument is not rooted in legacy considerations. If we were to sit down
today and build a "compact" binding mechanism, it would end up looking a
lot like XPConnect - including lack of support for the full expressiveness
of WebIDL. If there are specific places where we believe we could have our
cake and eat it too, we should just fix XPConnect.

On Fri, Mar 9, 2018 at 4:21 AM, Ted Mielczarek <t...@mielczarek.org> wrote:

> On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
> > (C) The API uses complex arguments like promises that XPIDL doesn't
> handle
> > in a nice way.
>
> I think this is an understated point. WebIDL was designed explicitly to
> allow expressing the semantics of JS APIs, where XPIDL is some arbitrary
> set of things designed by folks at Netscape a long time ago. Almost any
> non-trivial API will wind up being worse in XPIDL (and the C++
> implementation side is worse as well).
>

XPIDL works totally fine for basic methods, getters, and setters. Modern
DOM APIs use higher-level stuff, and we have to implement those with
generated C++ to maintain the strict boundaries and semantics mandated by
the spec. But for internal APIs, it seems very reasonable to keep the
JS<->C++ glue somewhat bare-bones, and implement any desired higher-level
abstractions in JS.

There will always be exceptional cases, and that's fine. But developers
need to weigh their ergonomics against any impact product quality - and
while it might be nicer to implement a niche devtools API with promises and
unions, that doesn't mean it's the right thing to do.

Code size is like memory usage - it's an aggregate metric, and we don't
have hard-and-fast rules about specific cases, but we nonetheless expect
developers to be mindful of their impact and not over-spend without good
reason.

> I agree that an XPConnect-alike supporting WebIDL semantics would be a lot
> of work,

Not just that, but also probably intractable, as I described earlier.

> but I also think that asking developers to implement chrome interfaces
> with XPIDL is pretty lousy.

That strikes me as a bit of an overstatement. Do you have a concrete
suggestion of what we should do instead?

On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek <t...@mielczarek.org> wrote:
> On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
>> (C) The API uses complex arguments like promises that XPIDL doesn't handle
>> in a nice way.
>
> I think this is an understated point. WebIDL was designed explicitly to allow expressing the semantics of JS APIs, where XPIDL is some arbitrary set of things designed by folks at Netscape a long time ago. Almost any non-trivial API will wind up being worse in XPIDL (and the C++ implementation side is worse as well).
>

> I agree that an XPConnect-alike supporting WebIDL semantics would be a lot of work, but I also think that asking developers to implement chrome interfaces with XPIDL is pretty lousy.

An alternative would be to evolve XPIDL to be more WebIDL like. I
suspect we could fix some of the ergonomic warts incrementally with
significantly less work than supporting the full WebIDL semantics in a
XPConnect style.

-Jeff

On Fri, Mar 9, 2018 at 11:53 AM, Jeff Muizelaar <jmuiz...@mozilla.com>
wrote:
Absolutely. I filed bug 1444515 (alias xpidl-warts). Please document pain
points in that bug and we can brainstorm tractable fixes.


>
> -Jeff

> Kris Maglione <mailto:kmag...@mozilla.com>
> 2018 March 8 at 16:22
>
> Removing XPCOM entirely is not really a possibility. Removing
> XPConnect bindings entirely is... theoretically possible, but would be
> a monumental amount of work, and is not something I've heard anyone
> seriously suggest.
If we removed XPConnect bindings entirely and converted XPIDL interfaces
used only by C++ into concrete native classes, then what else would
continue to need XPCOM?

-myk

On Sat, Mar 10, 2018 at 11:11 AM, Myk Melez <m...@mykzilla.org> wrote:

> If we removed XPConnect bindings entirely and converted XPIDL interfaces
> used only by C++ into concrete native classes, then what else would
> continue to need XPCOM?
>

What's your definition of XPCOM? Look in xpcom/, there is a ton of stuff in
there that is unrelated to XPIDL...

Nick

> Nicholas Nethercote <mailto:n.net...@gmail.com>
> 2018 March 9 at 20:02

>
> What's your definition of XPCOM?

This is basically what I'm asking Kris. I define it as the system that
Firefox uses to make intra- and inter-language calls between C++ and JS
via XPIDL and XPConnect. I'm interested in what else it provides that
makes it so indispensable.

> Look in xpcom/, there is a ton of stuff in
> there that is unrelated to XPIDL...

Indeed, but that doesn't tell me how much of XPCOM would remain
essential to Firefox if we no longer used XPIDL.

For example, XPCOM supports component registration and overriding at
runtime. But it isn't clear that Firefox needs those features, now that
it no longer supports XUL extensions (unless perhaps for system extensions).

And xpcom/ contains a ton of stuff, as you say. But it isn't clear how
much of it is core to XPCOM and how much just happens to live in that
directory.

I'm not playing the devil's advocate. I'm genuinely curious about the
extent of XPCOM's feature set (and how well it aligns with Firefox's
current requirements).

-myk

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez <m...@mykzilla.org> wrote:

> Nicholas Nethercote <n.net...@gmail.com>

> 2018 March 9 at 20:02
>
> What's your definition of XPCOM?
>
> This is basically what I'm asking Kris. I define it as the system that
> Firefox uses to make intra- and inter-language calls between C++ and JS via
> XPIDL and XPConnect.
>

That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
the name XPConnect means "connecting Javascript to XPCOM"). But quibbling
over the definition isn't really useful.

> I'm interested in what else it provides that makes it so indispensable.
>

> Indeed, but that doesn't tell me how much of XPCOM would remain essential
> to Firefox if we no longer used XPIDL.
>

I think a better framing of your question would be "what could we remove if
we removed XPIDL/XPConnect".

The main platform feature that XPConnect relies upon is the interface
inheritance hierarchy derived from nsISupports, including the
QueryInterface method to bounce between them. Specifically, objects must
implement an interface in that hierarchy to be reflected out-of-the-box by
XPConnect. However, there are lots of bits of C++ code that use
QueryInterface as well, which would be more work to change.

The nsISupports hierarchy doesn't really cost us anything per se, certainly
not enough to justify the gargantuan task of trying to rip it out. Using it
heavily for performance-critical things can be slow (virtual methods plus
any QI overhead), but we should just fix those callsites when they come up.

> For example, XPCOM supports component registration and overriding at
> runtime. But it isn't clear that Firefox needs those features, now that it
> no longer supports XUL extensions (unless perhaps for system extensions).
>

XPConnect's dependency on runtime component registration is limited to the
platform objects we've implemented in JS. If we get rid of those, that
dependency goes away.

Getting rid of contract-ids entirely would entail some light modification
of XPConnect to provide a different way to instantiate platform objects
from JS, but the lion's share of the work would be fixing all the code
that's set up to work with the existing mechanism.

>
> And xpcom/ contains a ton of stuff, as you say. But it isn't clear how
> much of it is core to XPCOM and how much just happens to live in that
> directory.
>
> I'm not playing the devil's advocate. I'm genuinely curious about the
> extent of XPCOM's feature set (and how well it aligns with Firefox's
> current requirements).
>

XPCOM is a not-very-well-delineated hodgepodge of mostly-independent
things. We are free to modify or remove any pieces that are causing
problems, provided someone can demonstrate that it's worthwhile.


>
> -myk
>
>

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez <m...@mykzilla.org> wrote:
> Nicholas Nethercote

> 2018 March 9 at 20:02
>
> What's your definition of XPCOM?
>
> This is basically what I'm asking Kris. I define it as the system that
> Firefox uses to make intra- and inter-language calls between C++ and JS via

> XPIDL and XPConnect. I'm interested in what else it provides that makes it
> so indispensable.
>

> Look in xpcom/, there is a ton of stuff in
> there that is unrelated to XPIDL...
>

> Indeed, but that doesn't tell me how much of XPCOM would remain essential to
> Firefox if we no longer used XPIDL.
>

> For example, XPCOM supports component registration and overriding at
> runtime. But it isn't clear that Firefox needs those features, now that it
> no longer supports XUL extensions (unless perhaps for system extensions).

Just a quick note on this point - we shouldn't make any special
concessions for system add-ons (or any other Mozilla-published add-ons
like Test Pilot, Shield Studies, etc). Legacy add-ons kept us in a
confusing compatibility bind for many years, so I want to make sure
nobody feels that they need to be careful to preserve any form of
compat here.

While the overall compat story should be much simpler as everything
continues to migrate over to WebExtensions, there will still be the
possibility of bundling experimental WE APIs inside add-ons published
by Mozilla (which contain chrome-privileged JS code). The authors of
these add-ons will continue to be responsible for ensuring that the
release(s) of Firefox they are targeting can support their needs.

That said, there are tests for in-tree system add-ons (in
browser/extensions/) so any potential bustage for add-ons that
implement Firefox features (activity stream, screenshots, pocket, etc)
can be quickly found and fixed.

> And xpcom/ contains a ton of stuff, as you say. But it isn't clear how much
> of it is core to XPCOM and how much just happens to live in that directory.
>
> I'm not playing the devil's advocate. I'm genuinely curious about the extent
> of XPCOM's feature set (and how well it aligns with Firefox's current
> requirements).
>

> -myk
>
>
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

Also sprach Myk Melez:

> For example, XPCOM supports component registration and overriding
> at runtime. But it isn't clear that Firefox needs those features,
> now that it no longer supports XUL extensions (unless perhaps for
> system extensions).

I believe this is a feature we rely on for bypassing invalid TLS
certificates in Marionette by replacing nsICertOverrideSerivce [1].

On 3/26/18 6:29 PM, Myk Melez wrote:
> Do any of those bits of C++ code depend on a particular feature of
> XPCOM

They depend on the dynamic casting provided by QueryInterface.

That said, they could in many cases switch to other methods of dynamic
casting that are more limited...

> or do they just happen to use it to access components whose
> interfaces would just as effectively (modulo the work required to
> convert them) be exposed as concrete native classes?

That happens as well.

> There's also a developer ergonomics issue, as Components/QueryInterface
> is more complex and cumbersome than other JS interfaces to native code
> (WebIDL, Node.js Addons, etc.).

Note that XPConnect did support other ways of exposing things like
constructors, at least on Window instances.  Ways we recently removed,
because implementing the back end of such things was painful enough that
nothing except the DOM (broadly speaking, as in web-exposed stuff)
bothered to in practice, and the DOM is now on WebIDL.

> We've worked around that to some extent with Services.jsm and other hacks.

I think we should think about other ways to address such pain points as
needed.  Please file blockers for
https://bugzilla.mozilla.org/show_bug.cgi?id=1444515

>> XPConnect's dependency on runtime component registration is limited to the
>> platform objects we've implemented in JS. If we get rid of those, that
>> dependency goes away.

> There are quite a few of these, if this search is accurate:

Yes, there are.

> Worthiness is relative to both effort and timeframe. That is to say: if
> something would take a lot of work but would pay off in the long run,
> then it may be worth a long-term (1-3 year) project for a small number
> of engineers, even if it isn't worth a short-term effort that diverts a
> large number of them.

I think we all agree on that.  The devil is in the details.  ;)

-Boris

> Bobby Holley <mailto:bobby...@gmail.com>
> 2018 March 12 at 12:25

> That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
> the name XPConnect means "connecting Javascript to XPCOM"). But quibbling
> over the definition isn't really useful.

I was aware that XPCOM predated XPConnect (although I didn't realize
that it predated XPIDL). Regardless, I agree that quibbling over the
definition isn't useful. However, it's useful to understand our
respective definitions, so we know what we're each talking about.

> The main platform feature that XPConnect relies upon is the interface
> inheritance hierarchy derived from nsISupports, including the
> QueryInterface method to bounce between them. Specifically, objects must
> implement an interface in that hierarchy to be reflected out-of-the-box by
> XPConnect. However, there are lots of bits of C++ code that use
> QueryInterface as well, which would be more work to change.

Do any of those bits of C++ code depend on a particular feature of

XPCOM, or do they just happen to use it to access components whose

interfaces would just as effectively (modulo the work required to
convert them) be exposed as concrete native classes?

> The nsISupports hierarchy doesn't really cost us anything per se, certainly
> not enough to justify the gargantuan task of trying to rip it out. Using it
> heavily for performance-critical things can be slow (virtual methods plus
> any QI overhead), but we should just fix those callsites when they come up.

There's also a developer ergonomics issue, as Components/QueryInterface
is more complex and cumbersome than other JS interfaces to native code

(WebIDL, Node.js Addons, etc.). We've worked around that to some extent

with Services.jsm and other hacks.

> XPConnect's dependency on runtime component registration is limited to the
> platform objects we've implemented in JS. If we get rid of those, that
> dependency goes away.
There are quite a few of these, if this search is accurate:

https://searchfox.org/mozilla-central/search?q=component.*%5C.js&case=false&regexp=true&path=*.manifest

And some of them depend on JSMs. Although it isn't clear at first glance
how significant those dependencies are, nor how much work it would be to
replace them with C++ or Rust implementations.

> XPCOM is a not-very-well-delineated hodgepodge of mostly-independent
> things. We are free to modify or remove any pieces that are causing
> problems, provided someone can demonstrate that it's worthwhile.

Worthiness is relative to both effort and timeframe. That is to say: if
something would take a lot of work but would pay off in the long run,
then it may be worth a long-term (1-3 year) project for a small number
of engineers, even if it isn't worth a short-term effort that diverts a
large number of them.

-myk