Windows 8 blog explores Metro app memory use

Windows 8 allows for its Metro style applications to stay suspended in the memory of a PC when not in use. That means that when a user wants to restart a Metro app, it should begin again with almost no lag. In the latest update to the official Windows 8 blog, Microsoft group program manager Bill Karagounis writes about how the team has designed Windows 8 to reclaim memory on a PC, even with a number of Metro apps in suspended mode.

Karagounis writes that for Windows 8 desktop apps, "Windows will try to keep the most important (frequently accessed) pages of memory in the app’s working set." However, Metro apps have a different way of handling memory allocation. He writes:

Starting with the Windows 8 Consumer Preview, whenever Windows detects memory pressure on the system, it will repurpose nearly all the memory that suspended Metro style apps would otherwise hold onto. Windows 8 can reclaim this memory without having to terminate an app.

The blog entry gets highly technical as Kargounis talks about how Windows 8 is designed to put the whole working set of a Metro app that has been suspended on a disk. He gives an example by using screenshots of the Windows 8 task manager. In the screenshot above, a number of Metro apps are suspended and are taking up memory in a PC that has just 2 GB of RAM.

The next screenshot shows the effects on the PC's memory after Kargounis begins launching even more Metro apps. Windows 8 responded with its new memory allocation feature and emptied the working set of the suspended apps on a disk. The final result was that Windows 8 freed up 250 MB of RAM to run the Metro apps while also keeping the suspended apps in operation.

A Windows 8 app that's suspended on a disk may take a little longer to be restored once a user decides to return to it, depending on how large its working set is. Kargounis says that Microsoft is "...continuing to reduce the amount we have to write to disk for Metro style apps and further optimizing this feature." He adds that suspended Metro apps will close completely if memory usage enters what he calls a "critical" stage.

Image via Microsoft

Report a problem with article
Previous Story

The plot thickens: sources claim no Windows Phone 8 updates for WP7

Next Story

First Intel-based smartphone could launch this week

15 Comments

Commenting is disabled on this article.

butilikethecookie said,
They leave apps running in the background so toast can push mail, twitter, music track playing, etc. to you...or am I misunderstanding?

My understanding upon a couple of quick readings on a Metro app life cycle is such.

When it is active, it is active.

When a user switches Metro apps, the Metro app being "pushed aside" starts going into suspended mode.

The developer can design the app to have background tasks which will still run while the main app is suspended.

However, the developer must within 5 minutes of the app becoming suspended;

- Save all relevant session and user data to a persistent state.

- release all links and controls to exclusive resources such as file handles.

Once that is done, the app resides in memory as a suspended app waiting for the ResumedApp exception to fire off.

When that happens, code must be written to recover and restore the user and session data, check that data if it has become "stale" (outdated), update and stale data, and then have the program fully resume.

Perhaps it's just me, and always looking for where problems may arise, and/or not more fully understanding how to program this yet, but I see a ton of areas where problems can arise and stay hidden just for the sake of having some memory cleared up especially as programmers get used to designing apps to work within this environment.

Condere said,

The developer can design the app to have background tasks which will still run while the main app is suspended.

However, the developer must within 5 minutes of the app becoming suspended

An app has 5 seconds to save state when it's about to be suspended (which should be more than ample time for any app).

This is completely orthogonal to background tasks. The suspend/resume of the app itself doesn't affect background tasks, they have different rules.

Once that is done, the app resides in memory as a suspended app waiting for the ResumedApp exception to fire off.

When that happens, code must be written to recover and restore the user and session data, check that data if it has become "stale" (outdated), update and stale data, and then have the program fully resume.

This is not correct. When the app is resumed, all the user data and whatever else the app had in memory is still there. It literally just resumes execution exactly where it left off when it was suspended.

If the app was terminated while it was suspended (because of memory pressure) then the app will need to re-load its persisted state.


Perhaps it's just me, and always looking for where problems may arise, and/or not more fully understanding how to program this yet, but I see a ton of areas where problems can arise and stay hidden just for the sake of having some memory cleared up especially as programmers get used to designing apps to work within this environment.

The VS templates and numerous samples show the right way to do this, and for most apps it's super simple to implement this stuff. In JS for example, apps just register for the WinJS checkpoint event, and write out any app state when it's fired:
http://msdn.microsoft.com/en-u.../windows/apps/br229839.aspx

The general guidelines are here:
http://msdn.microsoft.com/en-u.../windows/apps/hh465088.aspx

Brandon Live said,

An app has 5 seconds to save state when it's about to be suspended (which should be more than ample time for any app).

This is completely orthogonal to background tasks. The suspend/resume of the app itself doesn't affect background tasks, they have different rules.

This is not correct. When the app is resumed, all the user data and whatever else the app had in memory is still there. It literally just resumes execution exactly where it left off when it was suspended.

If the app was terminated while it was suspended (because of memory pressure) then the app will need to re-load its persisted state.

The VS templates and numerous samples show the right way to do this, and for most apps it's super simple to implement this stuff. In JS for example, apps just register for the WinJS checkpoint event, and write out any app state when it's fired:
http://msdn.microsoft.com/en-u.../windows/apps/br229839.aspx

The general guidelines are here:
http://msdn.microsoft.com/en-u.../windows/apps/hh465088.aspx

Having not written a Metro app yet, I was just going off of the few quick read throughs of MS web sites earlier.

However, going back to them I still wonder if I am not correct. Here is the example code give on MS website

SUSPEND CODE
CoreDispatcher dispatcher = Window.Current.Dispatcher;

private void App_Suspending(object sender, object e)
{
// This is a good time to save app data in case the process gets terminated.
IPropertySet settingsValues = ApplicationData.Current.LocalSettings.Values;

// TODO: Save the app data
}

RESUME CODE
CoreDispatcher dispatcher = Window.Current.Dispatcher;

private void App_Resuming(object sender, object e)
{
// There are no special arguments for the resuming event
dispatcher.Invoke(CoreDispatcherPriority.Normal,
(object invokedSender, InvokedHandlerArgs invokedArgs) =>
{
// TODO: Refresh network data
}, this, null);
}

Again, not having written any code means I may certainly may be mistaken, but I see two commented lines in there that start with TODO. After the TODO, I see "SAVE APP DATA", as well as "REFRESH NETWORK DATA".

To me, that is MS telling me that I better put in some code to save the data before the suspending action finalizes, and that I better look to make sure that the data is correct as the program recovers from the suspended state.

Forgot the website;
http://msdn.microsoft.com/en-u...ows/apps/xaml/hh770837.aspx

Now without knowing anything else at the moment on how a developer can control a program's life cycle, this may cause some serious issues, no?

I think I need to spend some time again on my WIN8 laptop and check a few things, but here goes...

You create a Metro app that you plan on having monitor something, let's say every 5 minutes, and if something meets a predefined criteria, it will alert the user (beeping sound or something). A pretty basic business application type of program pretty much.

The user starts the app, and then goes to surf the web. IE becomes the active Metro app, and the monitoring app gets... Suspended?

When suspended, it doesn't monitor whatever you want monitored... and bad things happen???

How does that twitter Metro app work? Can you get updates or notifications when the Twitter app is "suspended"? I guess I have to create a Twitter account to check into this, because if this is how Metro apps work, I see this as a big flaw for PC apps.

Condere said,
Now without knowing anything else at the moment on how a developer can control a program's life cycle, this may cause some serious issues, no?

I think I need to spend some time again on my WIN8 laptop and check a few things, but here goes...

You create a Metro app that you plan on having monitor something, let's say every 5 minutes, and if something meets a predefined criteria, it will alert the user (beeping sound or something). A pretty basic business application type of program pretty much.

The user starts the app, and then goes to surf the web. IE becomes the active Metro app, and the monitoring app gets... Suspended?

When suspended, it doesn't monitor whatever you want monitored... and bad things happen???

How does that twitter Metro app work? Can you get updates or notifications when the Twitter app is "suspended"? I guess I have to create a Twitter account to check into this, because if this is how Metro apps work, I see this as a big flaw for PC apps.

Answering my own question...

http://www.microsoft.com/downl...displaylang=en&id=27411

Whitepaper on how to program Metro app to run background tasks when in suspended mode.

Condere said,
Now without knowing anything else at the moment on how a developer can control a program's life cycle, this may cause some serious issues, no?

I think I need to spend some time again on my WIN8 laptop and check a few things, but here goes...

You create a Metro app that you plan on having monitor something, let's say every 5 minutes, and if something meets a predefined criteria, it will alert the user (beeping sound or something). A pretty basic business application type of program pretty much.

The user starts the app, and then goes to surf the web. IE becomes the active Metro app, and the monitoring app gets... Suspended?

When suspended, it doesn't monitor whatever you want monitored... and bad things happen???

How does that twitter Metro app work? Can you get updates or notifications when the Twitter app is "suspended"? I guess I have to create a Twitter account to check into this, because if this is how Metro apps work, I see this as a big flaw for PC apps.

You should watch this video:

http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004

I hate that OS makers think that we want apps the remain running no matter how much RAM they do or do not use

I hate that feature in Android, and I hate that feature in 8, if I close an app I want it dead, not hanging around just incase I want to go back to it

Thats what the minimise buttons are for.

And even with Android, killing an apps process vs leaving it running and then opening it again has absolutely 0 difference in opening speed

We're not running P133's anymore, there is no need to try to improve app opening times by leaving them running

Just my opinion, when I hit close, I mean close. MS/Google thinking they know better than us.

if you close a metro app it is out of memory (far as im aware), what they are talking about here is when you swap to a different app while still leaving the old app running in the background.

Detection said,
I hate that OS makers think that we want apps the remain running no matter how much RAM they do or do not use

I hate that feature in Android, and I hate that feature in 8, if I close an app I want it dead, not hanging around just incase I want to go back to it

Thats what the minimise buttons are for.

And even with Android, killing an apps process vs leaving it running and then opening it again has absolutely 0 difference in opening speed

We're not running P133's anymore, there is no need to try to improve app opening times by leaving them running

Just my opinion, when I hit close, I mean close. MS/Google thinking they know better than us.

Metro apps close when you close them, all this post is talking about is when you do leave them running/open and what will happen when RAM runs low for some reason.

Detection said,
if I close an app I want it dead, not hanging around just incase I want to go back to it

Then just drag the app off the screen to close it. Problem solved.

Seems to work well. My computer is always running super speedy, and when something does eat all my rams, the metro apps only take a few seconds to get back up and running. Also Windows doesn't seem to slow down after a ram eating game is closed. Aka, I don't ever need to restart it.