Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimise bounds checking for memory and tables #38

Open
SimonJF opened this issue Jul 3, 2018 · 0 comments
Open

Optimise bounds checking for memory and tables #38

SimonJF opened this issue Jul 3, 2018 · 0 comments
Labels
optimisation something that needs doing for performance

Comments

@SimonJF
Copy link
Owner

SimonJF commented Jul 3, 2018

Currently, memory (and soon tables) require explicit bounds checks to ensure safety. This incurs an additional read, and certainly additional branches.

One technique to reduce this would be to use mmap to ensure that out-of-bounds accesses cause a segmentation fault, and then handle the segmentation fault by trapping. Thus, the assumption is that the memory access will succeed, but that there's a guarantee that a segfault will be raised on out-of-bounds accesses.

@SimonJF SimonJF added the optimisation something that needs doing for performance label Jul 3, 2018
SimonJF added a commit that referenced this issue Jul 27, 2018
Implements #38 for memory (but not tables).

Also cleans up a lot of spaghetti code for division, which I rewrote when debugging.

This PR enables implicit memory bounds checks by using mmap instead of malloc for linear memory. The key idea is to rely on hardware protection, as described in the original WASM paper, instead of explicit checks (although these can be re-enabled via the --explicit-bounds-checks flag.

Doing so yields significant speedups -- we are on par with (and sometimes beat!) V8 in the benchmarks I've tried.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimisation something that needs doing for performance
Projects
None yet
Development

No branches or pull requests

1 participant