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

Reply via email to