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 <lwag...@mozilla.com> 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 <lhan...@mozilla.com> 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 <bobbyhol...@gmail.com> >> 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 <lhan...@mozilla.com> 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 <jdemo...@mozilla.com> >> >> wrote: >> >> >> >> > On Fri, Sep 7, 2018 at 10:47 AM, Lars Hansen <lhan...@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-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 >> > > _______________________________________________ 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
