[exploration] Wasm's OffsetGuardLimit and HugeMappedSize can potentially be much smaller
Categories
(Core :: JavaScript: WebAssembly, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox103 | --- | fixed |
People
(Reporter: lth, Assigned: rhunt)
References
(Blocks 1 open bug)
Details
(Whiteboard: [arm64:m4])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Updated•7 years ago
|
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
Discussed this with Luke a bit. Really, since we can handle any size offset with a fallback path, we can reduce the offsetGuardLimit on all platforms, if we want to reduce the VM footprint. There is no magic per se about 2^31, though it may be the largest offset representable in an x86 instruction and so it may be "optimal" for that architecture if we don't consider VM footprint as a factor. In practice, and especially for wasm content, it is very likely that almost all offsets are quite small.
Assignee | ||
Comment 2•3 years ago
|
||
Two more thoughts from a discussion with Lars today.
- We've seen offsets as large as 1MiB in hot-paths. We need to thoroughly investigate a reasonable guard page size, and not just assume it.
- If we lower the guard limit size, our load/store instructions will only have to deal with smaller offsets (as we'll fold them into the base with a guard check when they're over the guard size limit), and we may be able to improve codegen on some platforms by assuming this.
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
We can use large v-mem reservations to omit bounds checks for 32-bit wasm
code. This requires at least 4GiB to catch any possibly dynamic index
given to a wasm memory access instruction. Memory accesses also can contain
a static 'offset' immediate which is to be added to the dynamic index
to get the effective address. To handle those, we reserve 'offset' guard
pages after the 4GiB main region. Any offset that is larger than the
offset guard region forces the access to have a bounds check.
Our current reservation is 2GiB, which is unreasonably large. After
profiling our internal wasm-corpus, the largest offset found was
~20MiB with most being <1MiB. 32MiB should therefore be more than
enough and reduce our vmem reservations by 33%.
Updated•2 years ago
|
Comment 5•2 years ago
|
||
bugherder |
Description
•