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

Allocate linear memory using mmap #3052

Merged
merged 1 commit into from
Feb 2, 2024

Conversation

loganek
Copy link
Collaborator

@loganek loganek commented Jan 18, 2024

With this approach we can omit using memset() for the newly allocated memory therefore the physical pages are not being used unless touched by the program.

This also simplifies the implementation. There's a room for further refactoring and unifying aot/wasm runtimes, but we can do it as follow-ups to keep the PR at reasonable size.

@loganek loganek force-pushed the loganek/mmap-all branch 30 times, most recently from ee99a85 to dc22faa Compare January 24, 2024 19:49
@loganek loganek changed the title [Draft] Allocate linear memory using mmap Allocate linear memory using mmap Jan 25, 2024
@loganek loganek marked this pull request as ready for review January 25, 2024 09:48
build-scripts/config_common.cmake Show resolved Hide resolved
core/iwasm/aot/aot_runtime.c Outdated Show resolved Hide resolved
@wenyongh
Copy link
Contributor

@loganek thanks a lot for the refactoring, I tried to review the code and added several comments. Since this is a big change which impacts many platforms (per my understanding, it's a breaking change) and hasn't been tested by developers for some time, could we leave it unmerged until WAMR-1.3.2 is released? I am afraid that it may be a little rushed to merge it because we want to release 1.3.2 soon.

@loganek
Copy link
Collaborator Author

loganek commented Jan 26, 2024

@loganek thanks a lot for the refactoring, I tried to review the code and added several comments. Since this is a big change which impacts many platforms (per my understanding, it's a breaking change) and hasn't been tested by developers for some time, could we leave it unmerged until WAMR-1.3.2 is released? I am afraid that it may be a little rushed to merge it because we want to release 1.3.2 soon.

Absolutely, let's not block 1.3.2 and we can pull it for the next release. And thanks a lot for the review, I'll address your comments in the upcoming days.

@loganek loganek force-pushed the loganek/mmap-all branch 7 times, most recently from ad45e49 to 00c4ba3 Compare January 29, 2024 12:15
@loganek
Copy link
Collaborator Author

loganek commented Jan 29, 2024

@wenyongh I've replied to all your comments, please let me know if you have any question, and feel free to merge the PR once 1.3.2 is released.

@wenyongh
Copy link
Contributor

@wenyongh I've replied to all your comments, please let me know if you have any question, and feel free to merge the PR once 1.3.2 is released.

OK, let's merge it after 1.3.2 and do more tests then.

@loganek loganek force-pushed the loganek/mmap-all branch 8 times, most recently from 7c26320 to 215b7c8 Compare January 30, 2024 15:31
With this approach we can ommit using memset() for the newly allocated memory
therefore the physical pages are not being used unless touched by the program.

This also simplifies the implementation.
@wenyongh wenyongh merged commit a27ddec into bytecodealliance:main Feb 2, 2024
393 checks passed
no1wudi added a commit to no1wudi/wasm-micro-runtime that referenced this pull request Feb 4, 2024
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
With this approach we can omit using memset() for the newly allocated memory
therefore the physical pages are not being used unless touched by the program.

This also simplifies the implementation.
@loganek loganek deleted the loganek/mmap-all branch June 10, 2024 12:47
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.

None yet

2 participants