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

Rewrite the way LLVM JIT does memory allocation to allow use of more than one contiguous segment #6771

Merged
merged 2 commits into from Oct 28, 2019

Conversation

rajkosto
Copy link
Contributor

I don't see why not ? Is this low area of memory used for anything else ?
Avoids LLVM out of memory fatal error when too many PPU modules get compiled and linked in.

Utilities/JIT.cpp Outdated Show resolved Hide resolved
@Nekotekina
Copy link
Member

Because this is not a reliable solution

@rajkosto
Copy link
Contributor Author

Would just changing s_memory_size to a larger value be more "reliable" ?

@Nekotekina
Copy link
Member

No, need to eliminate this approach to allocation completely.

@rajkosto
Copy link
Contributor Author

I've thought about writing a simple page-sized allocator into the space that's already there but since theres no deallocateCodeSection/deallocateDataSection functions that will ever be called anyway that would be a bit pointless, unless the allocator would just be there to allow usage of another memory region when the first one is exausted ?

@rajkosto
Copy link
Contributor Author

rajkosto commented Oct 16, 2019

I have written a new LLVM JIT memory allocator to take advantage of multiple segments so there really should be no way to get LLVM out of memory now (unless actual alloc call fails). Because LLVM can never deallocate JIT memory as it is now, I see no better way.

@rajkosto rajkosto changed the title Reserve as much low-memory for LLVM linked code as possible Rewrite the way LLVM JIT does memory allocation to allow use of more than one contiguous segment Oct 16, 2019
@rajkosto rajkosto force-pushed the morellvmmem branch 2 times, most recently from 0a620de to 9c2cc38 Compare October 16, 2019 07:33
@zombie167
Copy link

zombie167 commented Oct 16, 2019

Thank you very much! It works like a charm in MG4. I have encountered an unsolved PPU cache 137 modules compilation error before .The cache is compiled successfully with this build.

@Hopefullyidontgetbanned
Copy link

Hopefullyidontgetbanned commented Oct 26, 2019

this could fix Elveon not running on rpcs3, using llvm

@Nekotekina
Copy link
Member

Well, this approach can work for now. Although I don't get the point of calling reserve/reset instead of allocating all possible segments at startup.

@rajkosto
Copy link
Contributor Author

rajkosto commented Oct 28, 2019

Everything accessible in the low <2GB area is already reserved at startup.
The reserveAllocationSpace override is there so that we don't switch allocation segments mid-module (otherwise trampoline stuff, whose code path was never actually used before, can break).

@Nekotekina
Copy link
Member

I meant emulator startup. Code under MAP_32BIT path doesn't seem to do it.

@rajkosto
Copy link
Contributor Author

rajkosto commented Oct 28, 2019

Ok, I've changed the MAP_32BIT path to greedy reserve as much as it can as well.

@Nekotekina Nekotekina merged commit b49b4c8 into RPCS3:master Oct 28, 2019
@tamarindojuice
Copy link

tamarindojuice commented Oct 29, 2019

@rajkosto Hey you over here, i know you from Nintendo Switch scene ;)

(Sorry for the offtopic)

kd-11 pushed a commit to kd-11/rpcs3 that referenced this pull request Nov 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants