From b890cbdf35ef3ec70f87fcb52964c2f18e6a4b3f Mon Sep 17 00:00:00 2001 From: "Ben L. Titzer" Date: Mon, 2 Nov 2015 16:20:25 -0800 Subject: Fix the WebAssembly page size at 64KiB. --- AstSemantics.md | 14 +++----------- Nondeterminism.md | 4 ---- Rationale.md | 14 ++++++++++---- 3 files changed, 13 insertions(+), 19 deletions(-) diff --git a/AstSemantics.md b/AstSemantics.md index 1d91acc..a407c36 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -194,12 +194,11 @@ Out of bounds accesses trap. ### Resizing In the MVP, linear memory can be resized by a `grow_memory` operator. This -operator requires its operand to be a multiple of the system -page size. To determine page size, a nullary `page_size` operator is provided. +operator requires its operand to be a multiple of the WebAssembly page size, +which is 64KiB on all engines. * `grow_memory` : grow linear memory by a given unsigned delta which - must be a multiple of `page_size` - * `page_size` : nullary constant function returning page size in bytes + must be a multiple of 64KiB. As stated [above](AstSemantics.md#linear-memory), linear memory is contiguous, meaning there are no "holes" in the linear address space. After the @@ -212,13 +211,6 @@ operator may be added. However, due to normal fragmentation, applications are instead expected release unused physical pages from the working set using the [`discard`](FutureFeatures.md#finer-grained-control-over-memory) future feature. -The result type of `page_size` is `int32` for wasm32 and `int64` for wasm64. -The result value of `page_size` is an unsigned integer which is a power of 2. - -The `page_size` value need not reflect the actual internal page size of the -implementation; it just needs to be a value suitable for use with -`grow_memory`. - ## Local variables Each function has a fixed, pre-declared number of local variables which occupy a single diff --git a/Nondeterminism.md b/Nondeterminism.md index 8ab60d0..3a1efee 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -30,10 +30,6 @@ currently admits nondeterminism: shared memory, nondeterminism will be visible through the global sequence of API calls. With shared memory, the result of load operators is nondeterministic. - * The value returned by `page_size` is system-dependent. The arguments to the - [`grow_memory`](AstSemantics.md#resizing) and other - [future memory management operators](FutureFeatures.md#finer-grained-control-over-memory) - are required to be multiples of `page_size`. * NaN bit patterns in floating point [operators](AstSemantics.md#floating-point-operators) and [conversions](AstSemantics.md#datatype-conversions-truncations-reinterpretations-promotions-and-demotions) diff --git a/Rationale.md b/Rationale.md index 602f5bd..744c95b 100644 --- a/Rationale.md +++ b/Rationale.md @@ -106,10 +106,16 @@ tradeoffs. ## Resizing -Implementations provide a `page_size` operator which allows them to efficiently -map the underlying OS's capabilities to the WebAssembly application, as well as -to communicate their own implementation details in a useful manner to the -developer. +To allow efficient virtual-memory based techniques for bounds checking, memory +sizes are required to be page-aligned. +For portability across a range of CPU architectures and operating systems, +WebAssembly defines a fixed page size. +Programs can depend on this fixed page size and still remain portable across all +WebAssembly engines which employ efficient virtual memory techniques for bounds\ +checking. +64KiB represents the least common multiple of many platforms and CPUs. +In the future, WebAssembly may offer the ability to use larger page sizes on +some platforms for increased TLB efficiency. ## Linear memory disabled if no linear memory section -- cgit v1.2.3