Stream: git-wasmtime

Topic: wasmtime / PR #3153 Implement the memory64 proposal in Wa...

Wasmtime GitHub notifications bot (Aug 05 2021 at 22:12):

alexcrichton opened PR #3153 from memory64 to main:

This commit implements the WebAssembly [memory64 proposal][proposal] in
both Wasmtime and Cranelift. In terms of work done Cranelift ended up
needing very little work here since most of it was already prepared for
64-bit memories at one point or another. Most of the work in Wasmtime is
largely refactoring, changing a bunch of u32 values to something else.

A number of internal and public interfaces are changing as a result of
this commit, for example:

• Acessors on wasmtime::Memory that work with pages now all return
  u64 unconditionally rather than u32. This makes it possible to
  accommodate 64-bit memories with this API, but we may also want to
  consider usize here at some point since the host can't grow past
  usize-limited pages anyway.

• The wasmtime::Limits structure is removed in favor of
  minimum/maximum methods on table/memory types.

• Many libcall intrinsics called by jit code now unconditionally take
  u64 arguments instead of u32. Return values are usize, however,
  since the return value, if successful, is always bounded by host
  memory while arguments can come from any guest.

• The heap_addr clif instruction now takes a 64-bit offset argument
  instead of a 32-bit one. It turns out that the legalization of
  heap_addr already worked with 64-bit offsets, so this change was
  fairly trivial to make.

• The runtime implementation of mmap-based linear memories has changed
  to largely work in usize quantities in its API and in bytes instead
  of pages. This simplifies various aspects and reflects that
  mmap-memories are always bound by usize since that's what the host
  is using to address things, and additionally most calculations care
  about bytes rather than pages except for the very edge where we're
  going to/from wasm.

Overall I've tried to minimize the amount of as casts as possible,
using checked try_from and checked arithemtic with either error
handling or explicit unwrap() calls to tell us about bugs in the
future. Most locations have relatively obvious things to do with various
implications on various hosts, and I think they should all be roughly of
the right shape but time will tell. I mostly relied on the compiler
complaining that various types weren't aligned to figure out
type-casting, and I manually audited some of the more obvious locations.
I suspect we have a number of hidden locations that will panic on 32-bit
hosts if 64-bit modules try to run there, but otherwise I think we
should be generally ok (famous last words). In any case I wouldn't want
to enable this by default naturally until we've fuzzed it for some time.

In terms of the actual underlying implementation, no one should expect
memory64 to be all that fast. Right now it's implemented with
"dynamic" heaps which have a few consequences:

• All memory accesses are bounds-checked. I'm not sure how aggressively
  Cranelift tries to optimize out bounds checks, but I suspect not a ton
  since we haven't stressed this much historically.

• Heaps are always precisely sized. This means that every call to
  memory.grow will incur a memcpy of memory from the old heap to the
  new. We probably want to at least look into mremap on Linux and
  otherwise try to implement schemes where dynamic heaps have some
  reserved pages to grow into to help amortize the cost of
  memory.grow.

The memory64 spec test suite is scheduled to now run on CI, but as with
all the other spec test suites it's really not all that comprehensive.
I've tried adding more tests for basic things as I've had to implement
guards for them, but I wouldn't really consider the testing adequate
from just this PR itself. I did try to take care in one test to actually
allocate a 4gb+ heap and then avoid running that in the pooling
allocator or in emulation because otherwise that may fail or take
excessively long.

[proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Aug 05 2021 at 22:14):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 05 2021 at 22:16):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 05:11):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 05:23):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 14:04):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 14:05):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 18:40):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 18:53):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 19:31):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 20:44):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (Aug 06 2021 at 20:44):

cfallin created PR review comment:

A comment here about why we decided not to expand heap_addr to take the u64 would help document our discussion :-)

Wasmtime GitHub notifications bot (Aug 06 2021 at 20:44):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (Aug 06 2021 at 20:44):

cfallin created PR review comment:

Good catch (avoiding wraparound). Could you add a comment re: the saturation here to note this is protecting against offset + access-size overflowing?

Wasmtime GitHub notifications bot (Aug 06 2021 at 21:00):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 06 2021 at 21:00):

alexcrichton requested peterhuene for a review on PR #3153.

Wasmtime GitHub notifications bot (Aug 11 2021 at 22:29):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Aug 11 2021 at 22:29):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Aug 11 2021 at 22:29):

peterhuene created PR review comment:

Same comment as above re: mention of wasm pages.

Wasmtime GitHub notifications bot (Aug 11 2021 at 22:29):

peterhuene created PR review comment:

I think this commit is now out of date as it's now taking a size rather than page delta?

Wasmtime GitHub notifications bot (Aug 12 2021 at 14:40):

alexcrichton updated PR #3153 from memory64 to main.

Wasmtime GitHub notifications bot (Aug 12 2021 at 14:40):

alexcrichton merged PR #3153.

Last updated: Nov 22 2024 at 16:03 UTC