Skip to content

Allow wasm code to detect when pages are modified #22

Closed

Description

@pcwalton

JITting emulators like http://copy.sh/v86 incur significant slowdown by having to check whether pages have been modified in order to invalidate the jitcode for self-modifying code. This could be implemented with a SIGSEGV signal handler. However, that isn’t strictly necessary: all it would need is the ability to mark a page as “tracking changes” and have wasm able to ask whether changes occurred since the last time that page was so marked.

Activity

  1. bvisness commented on Nov 7, 2025

    @bvisness
    Collaborator

    What would be a comparable native API for achieving what you are looking for?

  2. pcwalton commented on Nov 7, 2025

    @pcwalton
    Author

    Something like:

    void memory_page_set_tracking_changes(void *addr);

    memory_page_set_tracking_changes clears the internal "changed" bit for the page beginning at the given addr, which must be on a page boundary, and marks it as tracking changes.

    bool memory_page_is_changed(void *addr);

    memory_page_is_changed returns true if the internal "changed" bit for the page beginning at the given addr is set or false if it isn't set. addr must be on a page boundary, and the page must have been marked as "tracking changes" via an earlier call to memory_page_set_tracking_changes.

    The "changed" bit for a page is set whenever any memory on that page is modified.

    Internally, this can be implemented by unmapping the page on memory_page_set_tracking_changes, catching the SIGSEGV, and in that signal handler setting the "changed" bit and then mapping the page. The reason for the memory_page_set_tracking_changes call is that unmapping the page is expensive, and we don't want to worry about "changed" bits unless the wasm application requests them.

    The use case here is invalidating jitcode on executable pages. JITting emulators like http://copy.sh/v86 need to efficiently detect changes to memory pages so that they can invalidate code corresponding to those pages. For more information, see v86's "how it works" section.

  3. pcwalton commented on Nov 7, 2025

    @pcwalton
    Author

    Come to think of it, this isn't needed if #23 is implemented, because with #23 and the virtual proposal the app can mark pages it wants to track writes to as read-only and then set a "changed" flag itself in a try-store handler. I'll leave this open, but I think #23 would be the more elegant solution.

  4. pcwalton commented on Nov 9, 2025

    @pcwalton
    Author

    I’m going to go ahead and close this in favor of #23.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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