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
