Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance implications of mapping vs bounds-checked allocations #2

Open
taralx opened this issue Mar 13, 2022 · 2 comments
Open

Performance implications of mapping vs bounds-checked allocations #2

taralx opened this issue Mar 13, 2022 · 2 comments

Comments

@taralx
Copy link

taralx commented Mar 13, 2022

Since one of the intended uses of this is for ArrayBuffers, I am wondering about the performance (and predictability) implications of using mapping operations on buffers whose sizes are not a multiple of a page size (and indeed may be smaller than a page). What is supposed to happen if you access past the end of a mapped buffer?

At one point I had envisioned a set of memory instructions that accepted an object pointer and performed bounds checks (WebAssembly/gc#109). Do you imagine that these mapping instructions would be able to take the place of those?

@dtig
Copy link
Owner

dtig commented Apr 11, 2022

Sorry for the late reply, I'm catching up after being out on vacation.

The proposal in this repository doesn't explicitly state this, but the proposed operators would take size in multiples of page size, and not as a number of bytes. My original thought was that accessing past the end of a mapped buffer should be an out of bounds check, but other options were mentioned in the design issue here - WebAssembly/design#1439.

By the mapping instruction do you mean the addition of fat pointers of fully dynamic memories?

@taralx
Copy link
Author

taralx commented Apr 11, 2022

Ah, it sounds like the answer is "no, these are page-sized objects". Mapping instructions are memory.map/memory.unmap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants