Decrease instances of the dreaded 2GB allocation error on macOS. Ish. #331
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I was thinking about the 2GB Executable Memory error that users experience, and decided to look into it again. I realized that this function actually predates macOS Catalina, and since it's building against an older SDK it'd have been going the "best effort" route due to no support for `MAP_32BIT`. However, Catalina actually introduced `MAP_32BIT` and made it more widely available in `10.15.4`. This is one of the differences in how this block of code executes (e.g, Linux vs macOS). `MAP_32BIT` can be used to request allocation below the 4GB boundary, which is what we're after here. The block itself is just separated entirely so as to not muck with the rest of the platforms, and I condensed the `MAP_JIT` check into here as well for brevity. I've tested the built version of this on 10.15.7 and 11.5 and not hit issues, but this should probably still be tested further.
…emove Rosetta check entirely.
…ed 2GB for (some) users who experience it.
NikhilNarayana
requested changes
Dec 31, 2021
jordan-zilch
pushed a commit
to jordan-zilch/Ishiiruka
that referenced
this pull request
May 17, 2022
…project-slippi#331) * Adds a macOS-specific `AllocateExecutableMemory()` I was thinking about the 2GB Executable Memory error that users experience, and decided to look into it again. I realized that this function actually predates macOS Catalina, and since it's building against an older SDK it'd have been going the "best effort" route due to no support for `MAP_32BIT`. However, Catalina actually introduced `MAP_32BIT` and made it more widely available in `10.15.4`. This is one of the differences in how this block of code executes (e.g, Linux vs macOS). `MAP_32BIT` can be used to request allocation below the 4GB boundary, which is what we're after here. The block itself is just separated entirely so as to not muck with the rest of the platforms, and I condensed the `MAP_JIT` check into here as well for brevity. I've tested the built version of this on 10.15.7 and 11.5 and not hit issues, but this should probably still be tested further. * Force 4kb page size alignment for macOS, formatting fixes * Apply the Rosetta 2 MemoryArena base finding code for x86_64 macOS, remove Rosetta check entirely. * macOS and the 2GB boundary, or: an unholy workaround to fix the dreaded 2GB for (some) users who experience it. * RoundPage ifdefd out of WIN32, comments explaining why
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements a macOS-specific
AllocateVirtualMemory()function that works around the various nuances across the supported macOS versions. I've given this build to quite a few people and they've reportedly experienced far less cases of errors in allocating below the 2GB boundary (but they can still happen, because on macOS this just isn't as reliable).I would 100% welcome Jos or someone looking this over and smacking me upside the head if this seems absolutely insane... but, hey, it works.
Ish.
macOS and MAP_32BIT
This codebase actually predates macOS Catalina, and since it's building against an older SDK it'd have been going the "best effort" route due to no support for
MAP_32BIT.However, Catalina actually introduced
MAP_32BITand made it more widely available in10.15.4. This is one of the differences in how this block of code executes (e.g, Linux vs macOS).MAP_32BITcan be used to request allocation below the 4GB boundary. We really want to get below 2GB, but the differences in this flag on macOS mean we still need to do some annoying workarounds to try and get low.The block itself is just separated entirely so as to not muck with the rest of the platforms, and I condensed the
MAP_JITcheck into here as well for brevity.