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

Round the number of pages passed to Memory.grow. NFC #22362

Closed
wants to merge 1 commit into from

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Aug 12, 2024

Without this the trace line below prints (somewhat confusingly):

growMemory: 80740352 (+1048576 bytes / 16.999984741210938 pages)

@sbc100 sbc100 requested a review from kripken August 12, 2024 18:51
src/library.js Outdated
@@ -190,7 +190,7 @@ addToLibrary({
// it. Returns 1 on success, 0 on error.
$growMemory: (size) => {
var b = wasmMemory.buffer;
var pages = (size - b.byteLength + {{{ WASM_PAGE_SIZE - 1 }}}) / {{{ WASM_PAGE_SIZE }}};
var pages = ((size - b.byteLength + {{{ WASM_PAGE_SIZE - 1 }}}) / {{{ WASM_PAGE_SIZE }}}) | 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big deal to add two bytes here I guess, but the only noticeable impact is to the debug logging below. How about adding the |0 inside there?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do, but I also think its better/cleaner if that value we pass at runtime is actually an integer. I imagine it could be confusing for folks debugging if they see attempts to grow by a some fractional number of pages.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ended up reusing the existing alignMemory function.. and optimizing that function at the same time. So now anyone using alignMemory will see a code size saving, but memory grow itself has a slight code size regression due to reusing this function.

Without this the trace line below prints (somewhat confusingly):

```
growMemory: 80740352 (+1048576 bytes / 16.999984741210938 pages)
```
@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 7, 2024

This change landed as part of #22666

@sbc100 sbc100 closed this Oct 7, 2024
@sbc100 sbc100 deleted the memory_grow branch October 7, 2024 17:23
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

Successfully merging this pull request may close these issues.

2 participants