Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Saam Barati]

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  
> wrote:
> 
> 
> 
> On Wed, Aug 29, 2018 at 4:10 Filip Pizlo  > wrote:
> 
>> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki > > wrote:
>> 
>> 
>> 
>> On Wed, Aug 29, 2018 at 3:58 Filip Pizlo > > wrote:
>> 
>>> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki >> > wrote:
>>> 
>>> 
>>> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo >> > wrote:
>>> 
 On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki >>> > wrote:
 
 Thanks!
 
 On Wed, Aug 29, 2018 at 3:22 Filip Pizlo >>> > 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  > wrote:
> 
 
 
> Posted this mail to webkit-dev mailing list too :)
> 
> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki  > 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 

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 4:10 Filip Pizlo  wrote:

>
> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki 
> wrote:
>
>
>
> On Wed, Aug 29, 2018 at 3:58 Filip Pizlo  wrote:
>
>>
>> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki 
>> wrote:
>>
>>
>>
>> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:
>>>

 On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
 wrote:

 Thanks!

 On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  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> 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
>
>
>>
>

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Filip Pizlo]

> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki  
> wrote:
> 
> 
> 
> On Wed, Aug 29, 2018 at 3:58 Filip Pizlo  > wrote:
> 
>> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki > > wrote:
>> 
>> 
>> 
>> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki > > wrote:
>> 
>> 
>> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo > > wrote:
>> 
>>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki >> > wrote:
>>> 
>>> Thanks!
>>> 
>>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo >> > 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.

-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 >>> > wrote:
 
>>> 
>>> 
 Posted this mail to webkit-dev mailing list too :)
 
 On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki >>> > 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

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki 
wrote:

>
>
> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:
>
>>
>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
>> wrote:
>>
>> Thanks!
>>
>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  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 
>>> 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

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:

>
> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
> wrote:
>
> Thanks!
>
> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  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.


> -Filip
>
>
>
>
>> -Filip
>>
>>
>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki 
>> wrote:
>>
>> Posted this mail to webkit-dev mailing list too :)
>>
>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki 
>> 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

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Filip Pizlo]

> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki  
> wrote:
> 
> Thanks!
> 
> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  > 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 > > wrote:
>> 
> 
> 
>> Posted this mail to webkit-dev mailing list too :)
>> 
>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki > > 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

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Filip Pizlo]

I don’t like this proposal.

If we are running low on memory, we should switch to bounds checked memory.

-Filip


> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki  
> wrote:
> 
> Posted this mail to webkit-dev mailing list too :)
> 
> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki  > 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

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

Posted this mail to webkit-dev mailing list too :)

On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki 
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