-
Notifications
You must be signed in to change notification settings - Fork 696
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -147,8 +147,9 @@ address for an access is out-of-bounds, the effective address will always also | |
be out-of-bounds. This is intended to simplify folding of offsets into complex | ||
address modes in hardware, and to simplify bounds checking optimizations. | ||
|
||
In the MVP, address operands and offset attributes have type `int32`, and heap | ||
sizes are limited to 4 GiB. In the future, to support | ||
In the MVP, address operands and offset attributes have type `int32`, and linear | ||
memory sizes are limited to 4 GiB (of course, actual sizes are further limited | ||
by [available resources](Nondeterminism.md)). In the future, to support | ||
[>4GiB linear memory](FutureFeatures.md#heaps-bigger-than-4gib), there will be | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
lukewagner
Member
|
||
a mode in which they have type `int64`. | ||
|
||
|
4 comments
on commit 57bdfbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of explicit check
operations keeps coming up; I guess what we need to see before including this is a demonstration of a significant category of optimizations where the engine wouldn't have been able to achieve the same optimization by the normal bounds-check optimizations, but with the check
inserted, the engine is able to prove safety. I can imagine cases, I'd just like to see it in practice. Because there seems to be a very real risk that overzealous insertion of checks could make things slower (viz., if they aren't found to be redundant with the internal checks inside loads/stores (think baseline compiler)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is interesting. @titzer could you file this as a separate bug? We could explore it, and I'd be OK for it to be in MVP if we can show it's useful, or leave for FutureFeatures if we don't get to it soon enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukewagner The compiler should be able to hoist bounds checks for multiple loads/stores with the same base using the guard page(s) trick without any need for traps/signal handlers, if the semantics for out-of-bounds memory access are: oob loads return an undefined value, and oob stores put values into an undefined location. In that case
load_i32(base+4)
load_i32(base+8)
store_i32(base+N, value)
could be turned into something like
tmp_base = clamp(base, limit)
load_i32(tmp_base+4)
load_i32(tmp_base+8)
store_i32(tmp_base+N, value)
given N+3 bytes of guard memory (the VM is free to pick appropriate sizes, and could even adopt dynamically to some degree). The advantage of this approach is that it should also work well with 64-bit addressing in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmeurer Given the shared goal of reducing sources of nondeterminism, we would really like the semantics for OOB to be "always trap". This is especially important for OOB since it's such a common bug and we expect a plethora of impl strategies across hardware and browsers so you run a real risk of apps becoming dependent on the impl details of one strategy (certainly we see this in native C++ apps).
I'm not sure I agree with a "mode" that changes the types of these bytecodes, and the v8-native-prototype just has different bytecodes for heap accesses that take a 64-bit index. We should probably have an issue to discuss that, but until then we might want to avoid committing to one choice.