Skip to content
This repository was archived by the owner on Jan 15, 2025. It is now read-only.
This repository was archived by the owner on Jan 15, 2025. It is now read-only.

bounds-checking strategies #3

@binji

Description

@binji

64-bit WebAssembly VMs can currently (with 32-bit memories) use page-mapping tricks to make bounds-checking fast. As soon as we have 64-bit memories, those tricks don't work anymore. We should investigate other methods for doing bounds-checking without having to use conditionals.

Here's a suggestion from @titzer

I think there are better tricks available to the engine for WASM64. E.g. the engine can allocate a second guard region of > 1TiB and emit one additional memory access to guard[index >> 24] before the normal access of the memory memory[index+base+offset]. The second guard region can be arranged so that any upper bits of the index being set results in an access to an unmapped page in the guard region.

Here's another suggestion from @backes

An alternative would be multi-level memory lookup, similarly to how page tables work on Linux. In a 64-bit address space, that would require at least three levels to keep the tables at each level at a manageable size. Two levels could still be implemented by only reserving (but not committing) the huge tables, but it would waste a lot of virtual address space.
Inaccessible regions can be memory-protected at each level (whole pages within each level), and pointers to inaccessible regions within an otherwise accessible page at a given level (in the last accessible page) would just point to a (global) inaccessible region.

That scheme would require two additional loads for each memory operation. I could image that to still be faster than a dynamic branch.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions