From:  Luke Wagner <lwagner@mozilla.com>
Date:  10 Sep 2018 21:57:17 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Wrappers

NNTP-Posting-Host:  63.245.210.105

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.

On Mon, Sep 10, 2018 at 6:30 AM, Lars Hansen  wrote:

> 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
>
> On Fri, Sep 7, 2018 at 7:56 PM, Bobby Holley 
> wrote:
>
> > 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.
> >
> > On Fri, Sep 7, 2018 at 2:11 AM Lars Hansen  wrote:
> >
> >> 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
> >>
> >> On Fri, Sep 7, 2018 at 11:05 AM, Jan de Mooij 
> >> wrote:
> >>
> >> > On Fri, Sep 7, 2018 at 10:47 AM, Lars Hansen 
> >> 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-engine-internals@lists.mozilla.org
> >> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
> >> >>
> >> >
> >> >
> >> _______________________________________________
> >> dev-tech-js-engine-internals mailing list
> >> dev-tech-js-engine-internals@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
> >>
> >
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>