On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki <yusukesuz...@slowstart.org> wrote:
> > > On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <fpi...@apple.com> wrote: > >> >> 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> 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. > >> -Filip >> >> >> >> >>> -Filip >>> >>> >>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki <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> 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 >>> 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
