1021223 - Speed up cross-compartment calls

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Terrence Cole [:terrence]]

Cross-compartment calls currently take on the order of 150-200ns on desktop and probably 15-20us on mobile. Given the increasing number of js-implemented DOM components and the large number of compartments in browser chrome, it would be nice to be able to make these calls faster, particularly on B2G.

Comment 1

[Bobby Holley (:bholley)]

JS-implemented DOM components generally don't go use CrossCompartmentWrapper::call. The WebIDL machinery manually converts arguments, enters the target compartment, and invokes the function.

I agree that in general, speeding up CCW is a good thing. I've done some previous work on this in bug 907937. I'm not sure how much obvious speedup is left, but I'd definitely be interested in hearing ideas.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> JS-implemented DOM components generally don't go use CrossCompartmentWrapper::call

True, but we (discussion between me, terrence, jorendorff) were semi-considering changing that if the performance can be made compelling enough (basically replacing our C++ glue with JS glue in the case of JS-implemented stuff).

That said, the chrome-to-chrome case and in-content cross-compartment cases are already enough to make this worth doing.

Comment 3

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #2)
> > JS-implemented DOM components generally don't go use CrossCompartmentWrapper::call
> 
> True, but we (discussion between me, terrence, jorendorff) were
> semi-considering changing that if the performance can be made compelling
> enough (basically replacing our C++ glue with JS glue in the case of
> JS-implemented stuff).

I'm rather opposed to that, since it weakens our security boundary. What performance-sensitive APIs are we implementing in JS?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> since it weakens our security boundary.

Does it, if we autogenerate or equivalent glue code that does sane coercions?  I think it would be just as secure as what we have right now.

> What performance-sensitive APIs are we implementing in JS?

I don't know.  People keep wanting to implement things in JS and worrying about the performance thereof, but no one is willing to give me specific answers on what perf-sensitive things they want to do.

In any case, that's not the only motivation for this bug, and at this point not even the main one.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #4)
> > since it weakens our security boundary.
> 
> Does it, if we autogenerate or equivalent glue code that does sane
> coercions?  I think it would be just as secure as what we have right now.

I'm concerned about the correctness of that glue code, especially if this is the only use of it because:
* It's easier to be fooled in JS than in C++
 We have the very simple guarantee that the C++ glue code is correct by virtue of the fact that it converts things between languages.
 
> > What performance-sensitive APIs are we implementing in JS?
> 
> I don't know.  People keep wanting to implement things in JS and worrying
> about the performance thereof, but no one is willing to give me specific
> answers on what perf-sensitive things they want to do.

I think we need to do a better job of communicating that JS-implemented APIs are a prototyping tool, and shouldn't be used for the kinds of APIs where you care a lot about performance.

Maybe I should draft an email to dev-platform to that effect?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I'm concerned about the correctness of that glue code

I'm pretty sure we can get it right, fwiw.  But yeah, we'd have to be very careful.

> and shouldn't be used for the kinds of APIs where you care a lot about performance.

Well... given our experience with Console, we may want to implement in JS just for the security benefits.  :(

But all this is somewhat off-topic for this bug....