RalfK wrote:
Two poblems: Windows is not a real multitasking environment, and Firefox became horrible especially everything with Javascript.
Yea, that's nonsense. It was sorta true 20 years ago, but modern Windows at the kernel level is quite remarkable. It'll multi-task your socks off.
cbmeeks wrote:
I know *exactly* why this happens. Well, not exactly but I know who's causing it. It's the networking stack. I literally have 20+ years of experience with this. Let me explain...
The only thing that locks up my Mac is waiting for an external, sleeping drive to wake up. That seems to freeze the UI (and likely everything else). I've never had the network stack freeze the system. Individual requests, sure, but not the system.
BigEd wrote:
Two other things: virtual memory means you may be paging to hard drive, and large memory spaces mean your application might be garbage collecting for a time.
Virtual memory is lousy on active processes. With modern, large server processes running systems that are garbage collected, swap is death. One trip through the garbage collector sweeping a swapped heap is thrash city, as it tries to page everything in. We have some servers with no swap at all, I'd rather processes fail "quickly" when they run out of resources than swap and just flail. Linux will kill the largest process it can find when it runs out of memory. That's honestly a better outcome than swapping it out first. Tuned correctly, the servers don't run out of memory. Running out of memory is a "bug". I can deal better with a dead program than a thrashing, seizing and unresponsive operating system.
commodorejohn wrote:
These are big ones as far as those 15-second delays go. What drives me crazy is how the entire system can grind to a halt if one application needs to swap. I've seen this on Windows, Mac, and *nix - run a browser with a bunch of tabs chewing up a couple GB, and the whole computer, from the UI layer down to other applications, starts to judder or just stops until the hard-disk light goes off. So much for multitasking!
Yea, if things are badly swapped out, everything is basically in suspended animation. I've had processes on my Mac (large source code check out among other things) just decide to fill up virtual memory and swap everything else out. Come back and, even after killing the offending process, you now have these barely conscious processes that need to be swapped in. And the display is a lie, you can have an active window with the process barely there. As soon as you activate it, it pages in, so it's a painful process of touching everything on your desktop to wake it up. Many times, it's simply just faster to restart, but that's not necessarily always doable.
Also, the modern Mac OS, has practically given up on swap. With SSD backed systems, what the Mac will do (with cooperating applications), when its memory pressured, is simply kill the application, but leave the window on the screen. When you activate the window, the Mac silently reloads the application and, ideally, you're just where you left off. This tech is lifted from iOS which does this all the time.
iOS is as much magic trick as it is anything else. But the plan is sound. On iOS it is cheaper (notably in terms of energy) to leave applications open than it is close out unused ones. The OS will simply kill things off when they're exhausted. iOS doesn't "swap" per se, it's easier to delegate that problem to the app developers who need to take in to account the idea of a "fast restart". It's not just that the OS can do this, recall the user can simply click the home button, at any time, and go back to the main menu. This is a perfect example of where the app should shut down, and save the current work, waiting to be recovered later. It may be killed right there, it may not.
Also, of course, on the Mac, the OS will leverage the virtual memory system to compress memory on the fly. This is a pre-stage state of an idle app, any memory pages just kind of quiet can be compressed transparently by the OS. So, Mac OS is actively moving away from swap.
DerTrueForce wrote:
I have trouble understanding why internet browsers eat such horrendous amounts of memory. And I think the multi-process model is partly a way to obfuscate how much memory/CPU time things are using. I'm pretty sure there's no real need to go multi-process. Multi-thread will probably cut it plenty fine.
Internet browsers eat horrendous amounts of memory because they cache a boat load of data. Because modern web pages are bloated sows of markup and javascript. Then you have the physical copy of the page, (i.e. the text loaded from the server) along with the internal memory model (the DOM), which is very rich. Then you have the javascript code itself, it's original text, it's internal, compiled byte code representation, and also the JITed machine code representation. 3 times the storage, 3 times the fun.
The multiprocess model is partly to keep bad pages from nuking the entire browser. A thread model can't save a process necessarily from a process level fault. But it's more designed to better sand box the pages with an eye toward security and cross tab exploits as much as anything.