> 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

Reply via email to