> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki <yusukesuz...@slowstart.org> > wrote: > > > > On Wed, Aug 29, 2018 at 3:58 Filip Pizlo <fpi...@apple.com > <mailto:fpi...@apple.com>> wrote: > >> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki <yusukesuz...@slowstart.org >> <mailto:yusukesuz...@slowstart.org>> wrote: >> >> >> >> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki <yusukesuz...@slowstart.org >> <mailto:yusukesuz...@slowstart.org>> wrote: >> >> >> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <fpi...@apple.com >> <mailto:fpi...@apple.com>> wrote: >> >>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki <yusukesuz...@slowstart.org >>> <mailto:yusukesuz...@slowstart.org>> wrote: >>> >>> Thanks! >>> >>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo <fpi...@apple.com >>> <mailto:fpi...@apple.com>> wrote: >>> I don’t like this proposal. >>> >>> If we are running low on memory, we should switch to bounds checked memory. >>> >>> How about using bound checking mode exclusively for low environment? >> >> That would mean that, paradoxically, having a machine with a lot of memory >> means being able to spawn fewer wasm instances. >> >> We want to support lightweight wasm instances because it wouldn’t be good to >> rule that out as a use case. >> >> Hmmm, can we compile the BBQ phase / initial wasm code without knowing the >> attached memory’s mode? The current strategy basically defers compilation of >> wasm module until the memory mode is found. >> Because of this, WebAssembly.compile is not so meaningful in our >> implementation right now... >> And wasm ES6 module can import memory externally. This means that we cannot >> start wasm compilation after the memory mode of the impprted memory >> (described in the imported modulr) is downloaded, analyzed and found. >> >> How about always compiling BBQ code with bound checking mode? >> It should work with signaling memory with small / no tweaks. And OMG code >> will be compiled based on the memory mode attached to the module. >> Since BBQ -> OMG function call should be linked, we need to call appropriate >> func for the running memory mode, but it would not introduce significant >> complexity. > > What complexity are you trying to fix, specifically? > > What I want is starting compilation before the memory is attached a.k.a. > instantiated) > > > I think that what we really want is an interpreter as our baseline. Then > tier-up to BBQ or OMG from there. In that world, I don’t think any of this > matters. > > Does this interpreter execute wasm binary directly? If so, we can skip > compiling and all should work well! > > Even if we want some own bytecode (like stack VM to register VM etc.), it is > ok if the compilation result is not tied to the memory mode.
I don’t know if it will execute the wasm binary directly, but whatever bytecode it runs could be dissociated from memory mode. -Filip > > If the compilation result is tied to the memory mode, then we still need to > defer the compilation until the memory mode is attached. > > > -Filip > > >> >> >> >> >> -Filip >> >> >>> >>> >>> -Filip >>> >>> >>> >>>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki <yusukesuz...@slowstart.org >>>> <mailto:yusukesuz...@slowstart.org>> wrote: >>>> >>> >>> >>>> Posted this mail to webkit-dev mailing list too :) >>>> >>>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki <yusukesuz...@slowstart.org >>>> <mailto:yusukesuz...@slowstart.org>> wrote: >>>> Hi JSC folks, >>>> >>>> In Wasm supported environment, our MemoryMode is a bit dynamic. >>>> When we fail to allocate WasmMemory for signaling mode, we fall back to >>>> the bound checking memory instead. >>>> >>>> But Wasm code compiled for signaling / bound checking is incompatible. If >>>> the code is compiled >>>> as signaling mode, and if we attach the memory for bound checking, we need >>>> to recompile the >>>> code for bound checking mode. This introduces significant complexity to >>>> our wasm compilation. >>>> And our WebAssembly.compile is not basically compiling: it is just >>>> validating. >>>> Actual compiling needs to be deferred until the memory is attached by >>>> instantiating. >>>> It is not good when we would like to share WasmModule among multiple wasm >>>> threads / workers in the future, since the "compiled" Wasm module is not >>>> actually compiled. >>>> >>>> So, my proposal is, can we explore the way to exclusively support one of >>>> MemoryMode in a certain architecture? >>>> For example, in x64, enable signaling mode, and we report OOM errors if we >>>> fail to allocate WasmMemory with signaling mode. >>>> >>>> Best regards, >>>> Yusuke Suzuki >>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
