Have you ever been motoring along in XP or Vista, opening up new tabs in IE7, running apps in the background, etc. and noticed new tabs don't show the pages, or that when you right-click a link, you don't get a context menu? Or have you ever opened a couple of dozen photos in Irfan View and found the last few come up with no menu, and don't respond to hotkeys?
Did this bring back memories of "low resource heaps" in Win9x, or the need to restart DOS/Win3.yuk PCs several times a day to keep MS Office apps running properly?
You aren't going crazy, and yes, it's the same problem. It's like deja vu all over again.
Background
Windows 3.x used two or three "heaps", i.e. areas of RAM set aside for certain items that are spawned by running programs. There was a GDI heap for graphic elements, a user heap for UI and other elements, and a "system" heap that may have been a logical view of the first two (it's been a while, and I hoped I never have to remember the details again).
When folks started multitasking in earnest, these heaps would fill up and cause crashes, half-drawn UI elements, or spurious "out of memory" errors. Adding RAM was as useful as adding a trailer to a removal van with a loading crew so dumb they insist on putting all metal objects in the glove compartment and then tell you "we're full" after moving your hi-fi.
Windows 95 design intended to move these heaps to 32-bit replacements, but it was found that doing so would break several applications (including, it was rumored, Excel 4.0) which wrote directly to heap objects in memory rather than using the proper API calls.
So Windows 95 went into a long public beta where these things were thrashed out. Win9x left some items in "legacy" 16-bit heaps, and proactively cleared heap allocations when closing down VMs. 32-bit and DOS programs were run in their own VM, so this curbed "heap leakage" for these, but as 16-bit Windows all ran in a single shared VM, any resident 16-bit Windows program (e.g. Bitware 3.x) could hold this VM open forever.
Pundits would smugly point out that NT was a "true" 32-bit OS which did not make such compromises. The "huge" 32-bit address range should mean 32-bit heaps would never run out again.
The broken rule is...
"Do not use finite global storage for the per-instance data of an unbounded number of instances".
There are several instances of this rule being broken, such as the way Windows Explorer "remembers" settings for different folders.
The converse rule...
"Do not scale a per-instance resource based on evolving global store capacity"
...is broken by IE''s grabbing of X% of total HD volume space for its web cache, as well as System Restore capacity allocation. The first example was only fixed in IE7; the second, continues.
NT broke the first of these two scalability rules. The NT developers did not fix the heap problem via dynamically-sized heaps that could expand up to the limits of 32-bit addressability. Instead, they set various arbitrary limits at various times, in fact reducing these between versions 3.1 and 3.5 of the original NT.
The fix
Apparently this has been a known issue at Microsoft, though most of us (myself included) didn't see the old "resource heap blues" for the first few years on XP. I found some good background coverage in blogs and elsewhere, but the fix (adjusting certain registry settings) comes with some caveats:
Please do not modify these values on a whim. Changing the second or third value too high can put you in a no-boot situation due to the kernel not being able to allocate memory properly to even get Session 0 set up.
I haven't applied the fix yet, but probably will, on my XP SP2 system with IE7 etc. If it holds up here, and I have complaints from Vista users, then I may apply the fix to my new Vista PC builds as well.
Coverage
As you can guess, some blogs have been quite hostile to Microsoft, and this one is no exception (to me, it seems as if these folks missed the "Scalability 101" lecture).
However, I can see some reasons why they may have chosen not to create a dynamically-resizing heap system.
One reason is to prevent DoS memory usage through deliberate leaks; another might be concern over exploitable race conditions that might arise if one process is creating heap objects while another deliberately releases heap space to provoke a downwards resize.
There may be unacceptable overhead in managing more scalable data structures, such as linked lists, if heap objects are accessed as often as I suspect they might be.
Whatever such reasons might be, I'd suggest Microsoft get their story up really soon, before the trickle turns to a flood and users twig onto why they can't do "too many things at the same time" on their PCs - especially given the usual Vista mantra of "it's slow and needs more resources, but that's so it can scale up to future needs" that I've been known to wave around :-)
No comments:
Post a Comment