From:  Lars Hansen <lhansen@mozilla.com>
Date:  10 Sep 2018 22:13:27 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Wrappers

NNTP-Posting-Host:  63.245.210.105

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

On Mon, Sep 10, 2018 at 3:57 PM, Luke Wagner  wrote:

> 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
>>
>
>