Wrappers

[Lars Hansen]

So what's the current story about dealing with wrappers inside the engine?

Here's why I ask: I'm implementing a prototype of reference types and
object types for wasm, and these are realized as opaque (ie no exposed
storage) TypedObject instances so that JS can also access them
conveniently. Some of the fields are pointer fields, and when they are
unrestricted ("anyref") they can be written from both JS and wasm.

Additionally, js can call wasm passing anyref parameters, which wasm can
then try to downcast to references of known type.

When wasm receives a pointer or reads one from an object field it really
does not want to unwrap it; it wants to use it as a raw pointer
immediately. (Unboxing an anyref to a TO pointer is currently expensive
anyway but we don't want it to remain that way.) So how much unwrapping is
needed?

Luke told me - as I remember it - that we're pretty much getting rid of
wrappers inside the engine, so that we never have to worry about
unwrapping, but a quick search shows a lot of CheckedUnwrap calls still
present in the code.

So: what's the story, and what's the status?

--lars

[Jan de Mooij]

On Fri, Sep 7, 2018 at 10:47 AM, Lars Hansen <lha...@mozilla.com> wrote:

> So: what's the story, and what's the status?
>

Bug 1357862 will eliminate a lot of wrappers (it requires some Gecko
changes still before we can enable it), but it will only get rid of
same-origin wrappers at first. There has been some discussion about
follow-up work to eliminate more wrappers, but I don't know if/when that
will happen.

Jan


>
> --lars
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>

[Lars Hansen]

Thanks. Same-origin should be plenty good for what I'm doing.

In the mean time, trapping / throwing when attempting to unbox an anyref
that needs to be unwrapped is probably fine.

--lars

[Bobby Holley]

I don't think we're anywhere close to a point where transparent wrappers
(js::CrossCompartmentWrapper) will go away, or can be ignored by SM devs.
Even after Jan's changes, we'll still use them for lots of things
(including Chrome->Content XrayWaivers).

For stuff that's super edge-casey, it may be ok to punt and throw, but we
don't want to get ourselves into a situation where CCWs gradually stop
working because devs stop caring about them. They're an important
engineering tool, and I don't doubt that we'll continue to rely on them and
find new uses.

[Lars Hansen]

I don't know enough about wrappers yet to have a definite opinion, but it's
my understanding that if I encounter a wrapper I can't just unwrap the
value and pass the resulting pointer on and let it escape unwrapped back
into content. If that is so, then we have a problem, because it means that
potentially every typed reference in wasm may need to be unwrapped, and
this will greatly increase the cost of all pointer operations in wasm,
notably field accesses through them. At the moment references are nullable
so we always pay for a null check but we hope to allow code generators to
ask for non-nullable pointers too; at which point a field reference is a
single indirect load. And indeed when there is a null check it might well
be handleable as a trap, the way we handle OOB accesses already.

(If I'm mistaken, and it's ok to unwrap something and let it stay unwrapped
and let the unwrapped pointer escape back into content, then things are
much simpler, as the unwrapping can take place during the unboxing from
anyref -> typed ref.)

--lars

[Luke Wagner]

You're right that, to correctly handle transparent wrappers, wasm would
have to do a lot of work to deal with them (they can't simply be unwrapped)
and I agree that we don't want to do that.

After Jan's work, the only case where normal Web content would see
transparent wrappers would be the case where two origins started
different-origin and then both set document.domain to dynamically become
same-origin... and an object created in one flowed into the other. So I
this is why I think bholley is right that we can just punt and throw for
now.

[Lars Hansen]

Right, and we don't even need to throw: type testing just fails when we try
to unbox anyref and we get a failed downcast; other ref types can't cross
the JS->wasm boundary at all at the moment. So it's literally zero effort
to deal with this now, I'm more worried about the longer term.

--lars

[Luke Wagner]

Longer term, I think we should consider putting all
synchronously-accessible realms in the same compartment which would mean
content never observed a transparent wrapper. (There are important
security/testing/defense-in-depth questions to answer here, but iirc, there
are reasonable answers.) Unfortunately, this wouldn't remove most of the
wrapper goo in the engine since it sounds like there is still a lot of use
of (full or partial) transparent wrapping from Web Extensions and Chrome
JS, but it would mean that we wouldn't have to do backflips to support
every last pathological spec corner case since the transparent wrappers
would only need to be Good Enough.