I would also expect bytecode interpreter compilation to be so much faster than JIT compilation that we could laziliy compile either: - When we instantiate - When functions are called for the first time
- Saam > On Aug 28, 2018, at 12:17 PM, Yusuke Suzuki <yusukesuz...@slowstart.org> > wrote: > > > > On Wed, Aug 29, 2018 at 4:10 Filip Pizlo <fpi...@apple.com > <mailto:fpi...@apple.com>> wrote: > >> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki <yusukesuz...@slowstart.org >> <mailto: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. > > Thanks, that sounds reasonable! > If the bytecode compilation etc. is disassociated from the memory mode, the > bytecode can be compiled before instantiated. It means that wasm module can > be shared between workers (like postMessage the wasm module having compiled > bytecode). And we can start compiling before the memory is attached > (instantiated). > > > > -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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
