1535731 - Build a better CallNonGenericMethod

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Jason Orendorff [:jorendorff]]

The problem CallNonGenericMethod solves is that some methods need to touch reserved slots of this but also have to cope when this is a cross-compartment wrapper.

The problem with CallNonGenericMethod is that it enters the realm of this, contrary to the spec. This is sometimes observable: if we create an object (e.g. throw a TypeError) while in the wrong realm, its prototype chain will be wrong—and we do in fact have numerous bugs and test262 failures about this.

It's hard to do better.

Ted and I discussed various hacks. We think it is actually mostly OK that we enter the wrong compartment here; almost all known bugs are about Error objects. So what if we just fix the exception-throwing case? We know when we're creating an exception, and there is probably a way to compute "the actual standard current realm" from the stack or something, even if cx->realm() is wrong.

I don't have time to work on this right now, so P3. Whenever I get back to streams I can look at it.

Comment 1

[Jason Orendorff [:jorendorff]]

Other minor issues with CallNonGenericMethod we would love to address:

• The name is unclear ("generic method" is spec jargon, and even if you know it, the whole is somehow more opaque than the sum of its parts.)

• Ergonomically, having a separate _impl method is a pain. Maybe something with a lambda?

Comment 2

[Jason Orendorff [:jorendorff]]

Note: This is spun off from bug 1535588. Tom Schuster observed that the unwrapped scheme Till and Ted and I introduced, for Promises and Streams, is (not his words) a horror show. We need something better, something at least as nice to use as CallNonGenericMethod, but ideally without the wrong-realm bugs.

Comment 3

[Jan de Mooij [:jandem]]

To play devil's advocate: how much of an issue is this in practice? We've been moving towards putting same-origin globals in the same compartment. In the browser this already works for same-origin iframes and all chrome code is in a single compartment. We could consider moving to compartment-per-site (eTLD+1) to eliminate most content-observable compartment boundaries.

If this is about test262 I wonder if we could use a separate annotation for "fails only with --more-compartments".