From 85196ded6569dfdd9a0814337ffee9756d565e0b Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Fri, 8 Apr 2016 11:54:35 +0200 Subject: [PATCH 1/2] Add current_memory --- AstSemantics.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/AstSemantics.md b/AstSemantics.md index f1031a83..c528d5ab 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -215,6 +215,10 @@ reserve the space up front or if enabling the reserved memory fails. When there is no maximum memory size declared, `grow_memory` is expected to perform a system allocation which may fail. +The current size of the linear memory can be queried by the following operator: + + * `current_memory` : return the current size of the linear memory in units of pages. + As stated [above](AstSemantics.md#linear-memory), linear memory is contiguous, meaning there are no "holes" in the linear address space. After the MVP, there are [future features](FutureFeatures.md#finer-grained-control-over-memory) From 93457e01bc401a48aed5b3798c933283368375df Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Fri, 8 Apr 2016 17:11:34 +0200 Subject: [PATCH 2/2] Adjust wording --- AstSemantics.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/AstSemantics.md b/AstSemantics.md index c528d5ab..eaa7507c 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -82,19 +82,20 @@ operators. The main storage of a WebAssembly instance, called the *linear memory*, is a contiguous, byte-addressable range of memory spanning from offset `0` and -extending for `memory_size` bytes which can be dynamically grown by -[`grow_memory`](AstSemantics.md#resizing). The linear memory can be considered +extending up to a varying *memory size*. +This size always is a multiple of the WebAssembly page size, +which is 64KiB on all engines (though large page support may be added in the +[future](FutureFeatures.md#large-page-support)). +The initial state of linear memory is specified by the +[module](Modules.md#linear-memory-section), and it can be dynamically grown by +the [`grow_memory`](AstSemantics.md#resizing) operator. + +The linear memory can be considered to be an untyped array of bytes, and it is unspecified how embedders map this array into their process' own [virtual memory][]. The linear memory is sandboxed; it does not alias the execution engine's internal data structures, the execution stack, local variables, or other process memory. -The initial state of linear memory is specified by the -[module](Modules.md#linear-memory-section). The initial and maximum memory size -are required to be a multiple of the WebAssembly page size, which is 64KiB on -all engines (though large page support may be added in the -[future](FutureFeatures.md#large-page-support)). - [virtual memory]: https://en.wikipedia.org/wiki/Virtual_memory In the MVP, linear memory is not shared between threads of execution. Separate @@ -152,7 +153,7 @@ interpreted as an unsigned byte index. Linear memory operators access the bytes starting at the effective address and extend for the number of bytes implied by the storage size. If any of the -accessed bytes are beyond `memory_size`, the access is considered +accessed bytes are beyond the current memory size, the access is considered *out-of-bounds*. The use of infinite-precision in the effective address computation means that @@ -217,7 +218,7 @@ to perform a system allocation which may fail. The current size of the linear memory can be queried by the following operator: - * `current_memory` : return the current size of the linear memory in units of pages. + * `current_memory` : return the current memory size in units of pages. As stated [above](AstSemantics.md#linear-memory), linear memory is contiguous, meaning there are no "holes" in the linear address space. After the