(03-21-2015, 03:59 PM)magumagu Wrote: [ -> ]Yes, it actually wants 16GB. The fact that we free it immediately is a bug. Note that it isn't actually allocating that much memory, just trying to reserve address space for fastmem. This hasn't been a problem on desktop OSes or Android; not sure why iOS doesn't like it.
If reserving the address space is really impossible on iOS, we'll need to modify the JIT to compensate for a different memory layout. Not impossible, but there would be a substantial performance penalty.
I looked more into this issue, and apparently iOS does limit the amount of addressable memory.
Somebody made a program that attempts to exhaust the addressable memory and found the limit of how much a process can take. If you run it in the simulator, there are no restrictions. However, on the actual devices, there are restrictions and they vary with each device. The highest amount he got was on the retina iPad Mini (that is 64-bit), which was around 2GB! Presumably, this amount would be even less for iPhones!
So, from here,
I could maybe try using setrlimit since we have access to root on a jailbroken device, or the only option is to modify the JIT as you said...
UPDATE: getrlimit(RLIMIT_AS) says it's already set to the maximum value...
up please!!
will pay $20 in cydia for an ps2 or dolphin emu, because it serves as motivation and not a waste of time for the developer. so we all win. I'm sure many people would do the same thing. pay for Emulator.
(07-12-2015, 06:51 AM)brujo5 Wrote: [ -> ]up please!!
will pay $20 in cydia for an ps2 or dolphin emu, because it serves as motivation and not a waste of time for the developer. so we all win. I'm sure many people would do the same thing. pay for Emulator.
I don't think that it would be my decision to charge for Dolphin iOS
I think that will only happen if all the devs come to an agreement.
I've also stopped work on this (for now). iOS just has too stringent limitations when it comes to memory management. One such limitation the latest iPhone only has 1GB of RAM (my 5S has the same, and ~700-800MB is already used by the OS with no apps running. also, I think the iPad Air 2 has 2GB?). This is made worse by the fact that there is no swap file, leaving the OS to start asking applications to free up memory if free RAM becomes too low. Then, if that still does not free enough RAM, it resorts to terminating applications. (Hopefully Apple will give the iPhones and iPads more RAM in the future.) Another limitation is that there is something (probably in the kernel?) that restricts the amount of virtual memory that each process can reserve/allocate. The limit is the amount of physical memory the device has. Now, Dolphin's memory layout calls for it to reserve address space located past the limit. This, of course, is not liked by the OS and it returns an error. There may be something we could do here to bypass this, but I'm not really confident about it.
If somebody wants to take a stab at it, here's a link to the
GitHub repo. Relevant lines to Dolphin's memory layout are located in MemArena.cpp and Memmap.cpp. Good luck! (Also, I'm so sorry about how the Dolphin-iOS Xcode project is integrated... I've since found a better way to integrate iOS applications with cmake after more having more experience with it.)
(07-12-2015, 10:41 AM)OatmealDome Wrote: [ -> ] (07-12-2015, 06:51 AM)brujo5 Wrote: [ -> ]up please!!
will pay $20 in cydia for an ps2 or dolphin emu, because it serves as motivation and not a waste of time for the developer. so we all win. I'm sure many people would do the same thing. pay for Emulator.
I don't think that it would be my decision to charge for Dolphin iOS I think that will only happen if all the devs come to an agreement.
I've also stopped work on this (for now). iOS just has too stringent limitations when it comes to memory management. One such limitation the latest iPhone only has 1GB of RAM (my 5S has the same, and ~700-800MB is already used by the OS with no apps running. also, I think the iPad Air 2 has 2GB?). This is made worse by the fact that there is no swap file, leaving the OS to start asking applications to free up memory if free RAM becomes too low. Then, if that still does not free enough RAM, it resorts to terminating applications. (Hopefully Apple will give the iPhones and iPads more RAM in the future.) Another limitation is that there is something (probably in the kernel?) that restricts the amount of virtual memory that each process can reserve/allocate. The limit is the amount of physical memory the device has. Now, Dolphin's memory layout calls for it to reserve address space located past the limit. This, of course, is not liked by the OS and it returns an error. There may be something we could do here to bypass this, but I'm not really confident about it.
If somebody wants to take a stab at it, here's a link to the GitHub repo. Relevant lines to Dolphin's memory layout are located in MemArena.cpp and Memmap.cpp. Good luck! (Also, I'm so sorry about how the Dolphin-iOS Xcode project is integrated... I've since found a better way to integrate iOS applications with cmake after more having more experience with it.)
The problem on iOS is that, at least according to the iOS App Programming Guide, the virtual memory manager only swaps out read-only sections... In theory that would mean that you are not only constrained by the amount of available address space, but you are also constrained by the amount of available RAM, if you are mapping with anything other than PROT_READ."
See
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/TheiOSEnvironment/TheiOSEnvironment.html
We are using PROT_READ | PROT_WRITE here, so it doesn't swap out? iOS devices don't have much physical RAM. If we are limited to this, it will be hitting this. Even though the newer devices have more RAM (1GB), the OS seems to use a lot more at the same time.
Apple has said the maximum virtual memory addressable by an app is 750MB as well.
dolphin emu is in mature state So it should be easy to optimize (think).
this is very recent ps2 emu alpha build for ios run whithout memory leaks
https://github.com/jpd002/Play-/issues/16#issuecomment-120720544
(07-13-2015, 04:27 AM)brujo5 Wrote: [ -> ](snip)
The problem on iOS is that, at least according to the iOS App Programming Guide, the virtual memory manager only swaps out read-only sections... In theory that would mean that you are not only constrained by the amount of available address space, but you are also constrained by the amount of available RAM, if you are mapping with anything other than PROT_READ."
See http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/TheiOSEnvironment/TheiOSEnvironment.html
We are using PROT_READ | PROT_WRITE here, so it doesn't swap out? iOS devices don't have much physical RAM. If we are limited to this, it will be hitting this. Even though the newer devices have more RAM (1GB), the OS seems to use a lot more at the same time.
Apple has said the maximum virtual memory addressable by an app is 750MB as well.
dolphin emu is in mature state So it should be easy to optimize.
this is very recent ps2 emu alpha build for ios run whithout memory leaks https://github.com/jpd002/Play-/issues/16#issuecomment-120720544
I have very little to no knowledge of Play's code or memory layout, but it might be much different than Dolphin. I might try to squeeze Dolphin's memory layout into the 750MB limit and see what happens. (other devs: Is there any reason why the memory mirrors, l1 cache, exram is stored very high in the address space..? (0x200000000+) I haven't looked at Dolphin's code in a long time)
EDIT: will try this later, too addicted to splatoon atm.
If you ran out of VRAM, just disable fastmem. Then we don't need any additional memory for direct memory access nor for the mirrors. But you will see a big slowdown in this way :/
all developers are welcome to help here!!
I think I'm getting closer. I decided to turn off fastmem, comment out all the mirrors in Memmap.cpp, and moved the fakevmem, exram, and l1 cache memory areas closer together. (I was really hesitant to do this because as degasus said, it results in a huge slowdown. However, I saw no other option that could work.) Now it appears to be crashing on the first instruction ran on the CPU thread with EXC_BAD_ACCESS. (
Image from Xcode debugger) I will investigate running JITs on iOS and see if there's something extra I need to do.
