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

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki <yusukesuzuki at slowstart.org>
wrote:

>
>
> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <fpizlo at apple.com> wrote:
>
>>
>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org>
>> wrote:
>>
>> Thanks!
>>
>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo <fpizlo at 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 <yusukesuzuki at slowstart.org>
>>> wrote:
>>>
>>> Posted this mail to webkit-dev mailing list too :)
>>>
>>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki <
>>> yusukesuzuki at 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 at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180829/b7c74b8b/attachment.html>