> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki <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. -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
