Change linear memory max to be a hint #431
Conversation
| section contains a possibly-empty array of *segments* (analogous to `.data`) | ||
| which can specify the initial contents of fixed ranges of memory. | ||
|
|
||
| The linear memory section may also contain an optional hint declaring the maximum |
There was a problem hiding this comment.
This might say "the expected maximum" to emphasize the non-normative nature of the hint.
|
lgtm, other than some minor wording suggestions above. |
|
Good points; updated as suggested. |
| native executables (see [binary encoding](BinaryEncoding.md#global-structure)). | ||
| A module may contain an optional section declaring the use of linear memory | ||
| by the module. If the section is absent, the linear memory operators | ||
| `load`, `store`, `memory_size`, and `grow_memory` may not be used in the module. |
There was a problem hiding this comment.
I'm not sure I understand what purpose this serves.
There was a problem hiding this comment.
This is actually summarizing a previous spec PR which forgot to update design repo to match.
There was a problem hiding this comment.
Could you mention this in Rationale.md?
There was a problem hiding this comment.
Do you mean adding a link to the spec PR or copying the summary from the spec PR to Rationale.md?
There was a problem hiding this comment.
Other places in Rationale.md link to GH, so I'll do the former.
There was a problem hiding this comment.
Sorry, was hanging out with @sunfishcode :-)
I just meant to explain why you can't validate memory operations when you don't have memory declared.
| @@ -112,6 +112,11 @@ to communicate their own implementation details in a useful manner to the | |||
| developer. | |||
|
|
|||
|
|
|||
| ## Linear memory disabled if no linear memory section | |||
|
|
|||
| See [#107](https://github.com/WebAssembly/spec/pull/107). | |||
There was a problem hiding this comment.
Looks good, the PR explains things pretty well :-)
Change linear memory max to be a hint
(Following up on #370.) Got to discuss this issue a bit more with @titzer and @dschuff. We found two root use cases:
grow_memoryFor the former use case,
maxactually isn't a great hint because it must be set quite conservatively (greater than the peak usage of the app for all possible executions). So a hint that could be non-fatally exceeded would be more accurate and thus useful to the VM. Also, a hint doesn't punish the dev/user for failing to anticipate a corner case where memory peaks higher than what the dev observed during testing when all the dev wanted was a little perf boost. Lastly, if the engine supports resizing, then it can be more aggressive about pre-allocating the max size since, if virtual address space gets tight in the process, the engine can release the extra preallcoated space and fall back on realloc.For the latter use case, what's needed is just an optional flag
no_resize(which constrains both the main module and all future dynamically-linked modules). After some impl discussion, there doesn't appear to be any major known needs in the current anticipated engine impls so it seems best to leave it out of the MVP until there is a demonstrated need. In a totally separate discussion about how JS can alias wasm linear memory, we found a pretty significant use case forno_resizethough: with threads, wasm linear memory could move at any time so we can't simply hand out a SharedArrayBuffer to JS (and the rest of the browser). Rather, we would need to restrict aliasing to only whenno_resizeis set and provide a threadsafe, but less efficient, copy in/out API fallback.