You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow wasm code to detect when pages are modified #22
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.
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.
boolmemory_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.
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.
Activity
bvisness commentedon Nov 7, 2025
What would be a comparable native API for achieving what you are looking for?
pcwalton commentedon Nov 7, 2025
Something like:
memory_page_set_tracking_changesclears the internal "changed" bit for the page beginning at the givenaddr, which must be on a page boundary, and marks it as tracking changes.memory_page_is_changedreturns true if the internal "changed" bit for the page beginning at the givenaddris set or false if it isn't set.addrmust be on a page boundary, and the page must have been marked as "tracking changes" via an earlier call tomemory_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 thememory_page_set_tracking_changescall 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.
pcwalton commentedon Nov 7, 2025
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.
pcwalton commentedon Nov 9, 2025
I’m going to go ahead and close this in favor of #23.