Can we drop supporting mixed Wasm::MemoryMode in one process?

# Yusuke Suzuki (2 days ago)

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:

Contact us to advertise here
# Filip Pizlo (2 days ago)

I don’t like this proposal.

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

# Yusuke Suzuki (2 days ago)

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?

# Filip Pizlo (2 days ago)

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 <mailto: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.

# Yusuke Suzuki (2 days ago)

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.

# Yusuke Suzuki (2 days ago)

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 Pizlo (2 days ago)

On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:

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

On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote:

On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org <mailto:yusukesuzuki at slowstart.org>> wrote:

Thanks!

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

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.

# Yusuke Suzuki (2 days ago)

On Wed, Aug 29, 2018 at 3:58 Filip Pizlo <fpizlo at apple.com> wrote:

On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:

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.

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.

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 Pizlo (2 days ago)

On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:

On Wed, Aug 29, 2018 at 3:58 Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote:

On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org <mailto:yusukesuzuki at slowstart.org>> wrote:

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

On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote:

On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org <mailto:yusukesuzuki at slowstart.org>> wrote:

Thanks!

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

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.

# Yusuke Suzuki (2 days ago)

On Wed, Aug 29, 2018 at 4:10 Filip Pizlo <fpizlo at apple.com> wrote:

On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:

On Wed, Aug 29, 2018 at 3:58 Filip Pizlo <fpizlo at apple.com> wrote:

>

On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:

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.

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).

# Saam Barati (2 days ago)

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

Want more features?

Request early access to our private beta of readable email premium.