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