Jump to content

Apps closing: Slaying the Virtual Memory Monster

Guest dwallersv
 Share

Recommended Posts

Guest dwallersv

Guest dwallersv

Posted
Posted (edited)

There has been a lot of action in the forum over the last six months regarding O2 RAM usage, apps being closed with plenty of memory left, all sorts of attempts at registry changes that ultimately failed to solve the problem, and on and on... until one of ourt resident Gurus, Chainfire, got to the bottom of the issue and fixed the whole thing with a patch that modifies both the OS, and Samsung's insanely conservative memory manager, TaskMonitor.exe.

Thanks to Chainfire, the problem is solved, and those of us that like to multitask and fully utilize the resources and capabilities of our great O2 hardware and capabilities now can.

However, fixing this problem so that system RAM resources can drop to a much lower threshold than Samnsung's 50MB find that, on occasion, we now get a new failure condition directly from the WM6 OS when memory is low, with a warning dialog and an opportunity to close some apps to fix it. This is much better than Samsung's "bull in a china shop" method of just crashing around in the application list closing stuff until it gets back to it's comfy threshold of 50MB.

Mysteriously, this seems to happen sometimes even when the free RAM is above the threshold set for the patch, and we really haven't understood why.

I've found the answer.

This article explains in detail what's going on, and why, even where there appears to be plenty of free RAM above the "action threshold", the OS can still be running out of memory, and require some things be closed. It's easy to understand, written for the layman, not requiring any deep Computer Science background. I'd recommend that anyone who's been following this saga read it.

However, if you're lazy, here's the simple upshot of the article: Drivers are loaded into an application's addressable memory space from the top down, and are shared across applications, occupying the same address range in every application where they were loaded by the first app that needed them. Application code and data is loaded from the bottom up, with data allocation growing upward.

So, it is possible to get in a situation where a driver loaded by some process is loaded relatively low in memory, relative to the upper part of addressible space, because that was all that was available at the time when it was loaded. Now, a second process comes along, and has to use the driver in that same location. Meanwhile the space above that driver clears out as other processes that were using those other drivers exit, or unload them, leaving free RAM above the in-use driver. This memory is counted in the overall "free RAM" statistic, but is inaccessible for application heap, variable allocation, etc., to grow in to. The driver low in memory is "stuck" there until everyone using it goes away, or releases it.

So, because of this, a data-intensive application can chew up available RAM below the "bottom" driver, bumping up against it, and the OS can no longer allocate any more RAM for memory requests, despite the fact that there is all this tantalizing free RAM up there above that "bottom" driver, inaccessible to the application.

The only way to resolve this is to kill off the processes that are using that driver. Period. Doesn't matter how much RAM is "freed" by closing applications and returning their process RAM resources to the OS. Free RAM will increase by closing these applications, but the memory address space collision for the distressed application will persist, and WM6 will still see a "low memory" situation that needs to be fixed.

Here are two pictures from the article that should make this visually understandable:

post-479152-1269020734_thumb.png post-479152-1269020757_thumb.png

In summary, three things can result in WM6 (not Samsung's TaskMonitor) popping up a warning and asking the user to close applications:

  1. Total free memory truly falls below the thresholds set in the registry for WM memory management
  2. One or more processes run out of Virtual Memory address space regardless of actual free physical RAM
  3. All 32 process slots are used, and another process tries to start (WM6 is limited to running 32 processes simultaneously)
If you do not apply Chainfire's patch, Samsung all but 100% guarantees that none of these conditions ever occurs by keeping the free RAM threshold above 50MB, automatically and silently, through their TaskMonitor.exe process. This is good, I suppose, for the absolutely dirt-dumb and ignorant user -- the iPhone-type -- that doesn't want anything more than what is shipped with the device, or can add through the carefully controlled "sandbox" of the manufacturer's or service provider's "app store".

OF course, we WM types are a far broader user base, with iPhone-like lemmings as well as sophisticated users who hack, develop apps, and all sorts of rich, interesting, awesome reshaping of the platform and its applications -- which vastly improves the capabilities and utility of our devices. It's sad that Samsung doesn't take the absolutely trivial, almost no-cost steps to support all of us, not just the Soma-injesting armies of iPhone Fanboys. In this case, all it would have taken is a slightly redesigned TaskMonitor application, a switch in the control panel, and a little documentation. Effort that would have been trivial if planned in the original product development (I'm well experienced with this, having been a software Project Manager, and then an R&D Director, for 15 years).

Edited by dwallersv
Link to comment
Share on other sites
Guest daskalos

Guest daskalos

Posted
Posted

I have a B7610 and cooked a ROM which I remove almost all Samsung apps, ported 6.5.5 build 23547 and change the pagepool

Someone in XDA reported that the build has "better memory management", though I'm really not sure what he meant or if this is even true.

So I experimented running multiple applications (14 apps simultaneously) and switching them from time to time to use each app, and checking my task manager if some these apps will auto close and also checking free RAM

There was only 20Mb free RAM left, and there were no apps auto closing, and I continue to switch and use apps, and still they do not auto close.

Then I ran my 15th application, which made free RAM only 19Mb, still switching apps, and still no auto closing.

Then I ran a 16th application, which auto closed 10 applications...

So I repeat this experiment several times, and found out that the threshold of the ROM before it auto closes applications is 18Mb, lower than that, it auto closes programs....

This is without using the auto close patch,

For me this is somewhat good 'cause before with a official rom, programs auto closes as early when RAM drops to 40mb

So I'm wondering, what made this little "improvement"? Someone also said that gwes is newer in 23547 build...

Anyway, anyone using 23547 notice this?

Link to comment
Share on other sites
  • 4 weeks later...
Guest nap_rz

Guest nap_rz

Posted
Posted
Which ROMs have this cooked in? This is explicitly forbidden!

1. thank you for the effort, I'm using it now

2. actually I haven't seen anyone cooked that app

3. yes I also wonder why you forbid such action?

4. as I asked in the other thread, what happened to rodrigo and cmonex who supposedly do the bounty for NK.exe hack or sort of to free up the reserved RAM? does this project vanished just like that?

Link to comment
Share on other sites
  • 8 months later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept