Elaborate on the semantics of page_size.

[sunfishcode]

This fills out the specification of the page_size operator a little.

[jfbastien]

One missing backtick here.

[sunfishcode]

Fixed.

[titzer]

What can page_size be used for in the MVP?

[sunfishcode]

@titzer The resize_memory operation.

[titzer]

What if we just limited memory sizes to powers of 2?

On Thu, Aug 13, 2015 at 7:14 PM, Dan Gohman notifications@github.com
wrote:

@titzer https://github.com/titzer The resize_memory operation
https://github.com/WebAssembly/design/blob/master/AstSemantics.md#resizing
.

—
Reply to this email directly or view it on GitHub
#296 (comment).

[jfbastien]

@titzer going from 2GiB to 4GiB seems like a big jump :)

Though changing page_size to be page_size_log2 would be interesting.

[titzer]

page_size = 1gb, problem solved :-)

On Thu, Aug 13, 2015 at 7:19 PM, JF Bastien notifications@github.com
wrote:

@titzer https://github.com/titzer going from 2GiB to 4GiB seems like a
big jump :)

Though changing page_size to be page_size_log2 would be interesting.

—
Reply to this email directly or view it on GitHub
#296 (comment).

[sunfishcode]

@titzer After thinking about it more, I agree. I removed the minimum page size.

[jfbastien]

lgtm

[titzer]

Sorry if I wasn't clear. What if we just limited memory sizes to powers of
2, which might obviate the need for page_size?

On Thu, Aug 13, 2015 at 7:50 PM, JF Bastien notifications@github.com
wrote:

lgtm

—
Reply to this email directly or view it on GitHub
#296 (comment).

[sunfishcode]

On 32-bit devices, powers of 2 are very big steps relative to the underlying address space. A device may be able to easily allocate more than 128 MiB contiguous address space to a wasm app, but not all of 256 MiB, for example.

[jfbastien]

@titzer the OS we run on imposes a minimum page size. I guess we can over-allocate, and tell the user where memory now ends?

[lukewagner]

With asm.js, we started with a power of 2 allocation and got pushback that even the 128, 256, 512, 1024 quantas were too coarse, particularly on 32-bit, so we loosened the restriction to "multiple of 16mb" (for the benefit of ARM operand2 immediate encoding). This power-of-2 limitation would be exacerbated in the many-small-wasm-modules-in-one-web-app use case we've discussed before.

[jfbastien]

Could we move this PR forward? I was looking for it in the repo, and just realized it was still uncommitted.

Small nit along the lines of #354, should this say "same type as the address' index"?

[jfbastien]

@sunfishcode reminded me that @titzer may want to chime in some more before we move this forward. Let's wait on him :)

[titzer]

I think we should just drop the language about int64 page sizes and
trapping, since I don't think there are any machines on the horizon that
don't fit the current requirements.

On Wed, Sep 16, 2015 at 1:41 AM, JF Bastien notifications@github.com
wrote:

@sunfishcode https://github.com/sunfishcode reminded me that @titzer
https://github.com/titzer may want to chime in some more before we move
this forward. Let's wait on him :)

—
Reply to this email directly or view it on GitHub
#296 (comment).

[sunfishcode]

WRT trapping, I agree. That's part of an older idea that is now removed.

WRT int64 page sizes, we can now reword this in terms of wasm32 and wasm64, which I think makes this clearer. What do you think of the updated text?

[titzer]

lgtm although the larger discussion around wasm32/wasm64 is probably still
not quite settled.

On Thu, Sep 17, 2015 at 4:56 PM, Dan Gohman notifications@github.com
wrote:

WRT trapping, I agree. That's part of an older idea that is now removed.

WRT int64 page sizes, we can now reword this in terms of wasm32 and
wasm64, which I think makes this clearer. What do you think of the updated
text?

—
Reply to this email directly or view it on GitHub
#296 (comment).

[jfbastien]

lgtms abound! Merging.