Hacker News new | past | comments | ask | show | jobs | submit login
iOS Safari and Memory Management (ilyabirman.net)
39 points by ymolodtsov 26 days ago | hide | past | web | favorite | 46 comments



It's unfortunate how widely "virtual memory" is misunderstood to mean "an unlimited dynamic swap file". Why phones don't have unlimited dynamic swap and "why cannot Safari just save what it has downloaded to disk" are effectively the same question, just asked about the browser instead of the kernel. It would wear out the NAND chips on phone-class storage too quickly.


It's no more "misunderstood" than "serverless", when someone feels the need to explain to the poor unwashed masses that servers are involved and your programs aren't being run using pixie dust. VM == Swap is shorthand that people have been using for well over two decades.


The word "serverless" is a new word which wasn't used for anything in particular, and it's fairly descriptive, as you don't have to manage severs, you just have code which runs whenever you make certain HTTP requests. Obviously there's a server involved, but you don't have to care about it (for the most part; obviously abstractions are leaky).

The phrase "vrtual memory" is old and still widely used, and it refers to... virtual memory. The memory addresses programs use are virtual addresses into virtual memory, and the kernel sets up lookup tables to let the CPU resolve that virtual memory address into a physical memory address. Saying that "VM == Swap" might be common, but it still seems completely wrong, and makes people make ridiculous claims such as "unlike on the Mac, there is no virtual memory on the iPhone".


In context of the article, do you really think that most readers on HN didn’t immediately know that the article was referring to a swap file?

If you search on google right now for “virtual memory” for articles geared toward everyday people, you will see that the common vernacular is to refer to it being the same as the swap file. It’s referred to that way in Windows now and I remember “turning off virtual memory” being a control panel option on MacOS System 7 in 1991.

If someone said that the “army was decimated” would you think, knowing how language has evolved, that they meant the army was reduced by 10% or that it was left in ruins? Would you go on to explain to the ignorant plebe and start a sentence with “well actually...”?

When the term “virtual memory” came into the vernacular of everyday people, it was understood to mean swapping to disk.

It’s the same old descriptivism vs prescriptivism debate. Most of the time when someone lands on the prescriptivism side it comes off as pedantic.

Would you correct someone who said that they were buying a PC instead of Mac and say “well actually a Mac is s personal computer therefore it is also a PC”?


”and I remember “turning off virtual memory” being a control panel option on MacOS System 7 in 1991”

I think that truly turned off virtual memory (Mac OS 7 didn’t have separate address spaces, did it?)


No it didn’t. There was only one address space. So yeah, it did literally turn off virtual memory.

I went down a rabbit hole trying to remember the technical details of VM back in the day:

https://retrocomputing.stackexchange.com/questions/2804/why-...

[old man rant] I remember having at the time an obscene 10MB of RAM in 1992 for my Mac LCII to avoid using VM and to run Soft PC acceptably.

Then I had a whopping 24MB of RAM two years later for the PowerMac 6100/60 because it shared RAM with the DX2/66 DOS Card.

Then two years later I bought 32MB of RAM to attach directly to the DOS Card... [/old_man_rant]


>The word "serverless" is a new word which wasn't used for anything in particular, and it's fairly descriptive

Using it to describe distributed systems comes to mind, and would be more sensible than its current, mistaken use.


I guess I was giving the author the benefit of the doubt... saying "I understand why there's no swap, but why can't it just write to disk when memory gets low?" is nonsensical.


There is a difference between the app writing disk before it purged a web page and letting the OS page memory. Safari could theoretically be more intelligent about it.

Or it could only swap pages that contain form fields where the user has entered data as a last resort.


"VM == swap" is an indicator for me to not hire that candidate


So is someone saying “serverless” when they say they wrote a backend using Lambda also an indication?


Yes


What is phone-class storage? Swap definitely does not wear out good SSD in typical scenarios. Why are phones different?


Prioritize power usage and physical density over write cycles.


> My photos and videos don’t get destroyed when the phone is low on memory, why webpages should?

Well, they can be. That is, my iOS devices are set to have only thumbnails (plus most recently taken/viewed) on the device and dynamically load anything I want to look at (upscaling the thumbnail and then faulting in the full picture). The device memory is treated as a cache which can be flushed as needed.

It makes sense for Safari to do the same since most pages are reloadable (I wonder what it does with nocache-marked pages). And in particular, old tabs are unlikely to be looked at again. You can do some experiments: I'd bet forms are not purged either.


Forms are almost always purged. Had it happened with Google Forms.


This seems like a... misguided question. How did it make the front page? Was it just because lots of people chimed in with corrections?


That made me chuckle. Reminds me of the temptation to upvote every comment upstream of yours so that your snarky response gets more visibility even though the whole thread should probably be downvoted and sunk to the bottom.


This is a thing I never was able to understand — why it just doesn't cache the state of the page? I'd never even try filling a complicated web form on the iPad because it can reload the webpage anytime it pleases.


This happens to apps like Instagram, too. I could be making a post, have the photo all edited, put in 27 hashtags, then go to Safari to research another tag and... Come back and the entire app reloads, without saving the draft.


I think this is Instagram's fault, there have been lots of times where I absentmindedly leave the Instagram app for the home screen and tap on Instagram again a second later and the app reloads. My hunch is that it earns them another chance to show ads.


It could also be iOS aggressively killing resource hog apps, as it tends to do. As a dev, I’ve found that the apps that I work on almost never get killed by the OS, sometimes sitting in memory for several days, because they’re quite conservative with resource use. Many of the (often needlessly) heavier apps by the “big guys” on the other hand get killed on a regular basis, even on devices with a lot of RAM.


Facebook definitely does not care about the user returning to the same place, ever, or having any sort of continuity or coherence. I think that they do bank on confusion somehow making them more money. What I dislike is opening Instagram, and it shows me posts loaded the last time, and I want to click on them... But before I can, it reloads and shows me an entirely new semi-random selection of posts. Basically just like the Facebook news feed, you might see things that you wish to go back to, but have no hope of finding them ever again unless you have a great memory and are very dedicated.


Your device may be low on storage. I've done what you've described, and come back hours later with the app still in the same state, even with video.


It was only an iPhone 6, and sometimes I was low on storage, not other times. Storage depended on whether iCloud was actually syncing photos or not. I assumed that it was about being on low on resources, since it was an iPhone 6 running 2019 Instagram.


The iPhone 6 was a dog, unfortunately.


I was fairly satisfied with it overall, especially given did I bought it outright for a low price. However, recently the home button stopped working after less than two years.


Browsers are not editors. I think it is that simple - mentally, the model is browsers are for consumption, so who cares about state?

Contrast that with people writing editors - the mere idea of tossing the user's edits randomly is simply absurd.

Add in creepy surveillance features like javascript to capture your pre-submit edits and the other awful crap people get up to, and I write things in editors and paste in to browsers.


iOS does have virtual memory, it just doesn't swap pages to disk. The first iPhone had very slow flash, so swapping pages would totally kill performance.


More relevantly, swapping pages to flash storage would kill the flash storage itself. (Flash memory has terrible write endurance, and what endurance it has relies on obscure GC algorithms that would interact quite terribly with a "swap file"-like pattern!) Performance isn't actually a huge concern until you start swapping out your working set (i.e. actively threshing); even swapping to spinning rust, which has terrible performance, is better than having no swap at all!

Edit: You could still swap out to "external", modular storage like an SD card, since killing that would be no big deal - just treat it as disposable. But no SD card slot on iPhones :-P


It's a shame we all still go around with the first iPhones in our pockets for sure :)


I think in most cases the tradeoff of re-initializing app state, or forcing developers to cache state to disk manually is better than forcing the poor phone's disk to constantly swap and having developers be lazy and consume a ton of RAM.


Using iPhone 8 Plus 256GB so I can't agree with other commenters this behaviour is due to low storage. I have about 180GB free.

It seems Safari / iOS memory management isn't very clever. Sometimes Safari reloads pages I just left. Super annoying if you started filling out something there.

I don't understand why they don't just unload apps / pages on an LRU principle: whatever you do, do NOT unload an app / page the user was just in.

I like a lot of things about the iPhone and iOS but this peculiarity ain't one of them. It feels very backwards.

---

EDIT: I also heard the storage is almost at the laptop SSD class (if not better). So I am not sure swapping memory to it here and there would amortise it that badly. But I don't know for sure so not claiming anything.


I don't know for certain, but I do have a guess. Web pages are not represented in browsers as a contiguous block of memory. They are represented as thousands of objects that contain bits of data and point to other objects, GPU resources, etc. I suspect it would be absurdly complicated to serialize these objects to a form that could be stored on disk.


Operating systems have been serializing arbitrary application memory to disk for decades. Virtual memory makes it trivial. You swap a whole page out to disk, and mark the page “not present” in the page table. When the app tries to access that page, you get a page fault. The kernel handles the page fault by copying the page back to memory (at an arbitrary page-aligned location in physical memory) and updating the page table to point to that location. You never need to serialize the browser data structures.


As the fine article tells, there is no swap on iOS. It sounds like a great solution for the case where there is swap.


Most of these resources should be easy to recreate. Basically you need to save DOM, JavaScript objects, things like timers. It should be possible.


You have to save a huge amount of state. The complete JS object graph, the page layout, torn off elements, network requests, separate threads (the workers), etc, etc

Sure this is technically possible, because we already know that it’s possible to suspend a virtual machine, but that doesn’t mean it’s a reasonable use of engineering resources.

It also fails to acknowledge the very first problem: IOS doesn’t use swap because of flash wear (or something?), but what you’re proposing is essentially inventing the same problem again, but this time in user space with a pile a expensive heap traversal added for fun.


When browser reloads a page, that's a terrible UI. Very few websites save user data in local storage or somewhere else. You'll just lose your data. That does not happen on PC, but that does happen on mobile phones. Saving all memory surely will be more expensive than saving a select subset of memory.


you’re right, it is a bad UI, but the problem isn’t a matter of “just save the page state”. That already happens when you go back and forward - there’s literally a concept in browsers called the “back/forward cache” that is responsible for you not losing stuff that you entered on pages. Interestingly this also maintains a greater semblance of just working because a lot of network session info is kept around as well - things are ostensibly “per page load”, like session cookies through to session keys.

The problem is how do I save page state such that in critically low memory situations I can recover that state?

On a full system you can always page to disk - that’s how they keep the appearance of everything running. The downside is that swapping is bad for Flash storage, and apparently more so for the low power stuff you get in phones.

Now your statement “saving all memory is surely more expensive than saving some” isn’t actually correct.

First you have to define what “some” is: the entire dom, the js heap, network resources, and additional worker threads. Those are the vast bulk of the memory already being used - there’s not much else that isn’t already either torn down before a tab is killed or shared across processes (like the text segment, etc).

So we don’t end up meaningfully reducing how much needs to be stored.

Taking us to the next step: how do we selectively store just this “reduced” memory?

The reality is you end up having to add a bunch of additional metadata to the browser’s data structures. Which increases the frequency you hit the event you’re trying to avoid. It also means you have to maintain that metadata, providing a new source of bugs (I would consider highly likely), and using more cpu time (though I suspect not by much).

Finally, let’s say you have all of the logic to allow you to serialise everything needed to bring the page back up, when do you do it?

Tabs (or rather the process rendering the tab) are killed when the system is under memory pressure. Serialising requires a bunch of memory - it needs the space for the serialised page (let’s be generous and say 50% of the existing memory usage), it also needs space for the serialisation state, which is likely to be a bunch of O(Number of heap objects) maps.

That means the first thing a web process does when given a memory pressure warning is allocate a huge amount of memory, which would presumably fail (its a memory pressure situation), and then not be able to continue, and then get killed.

Even if you could serialise straight to disk (bad because aforementioned swapping vs SSD) you still get everything killed because you can’t store the serialisation state itself to disk, it has to be resident. Then what happens is you encounter memory pressure and every browser process simultaneously starts trying to serialise their current page, so all allocate a pile of memory for their serialisation state, and again you’re in the position of having a bunch of memory allocation requests when you by definition have little memory left.


His comments about iOS not having virtual memory are incorrect, but I rarely if ever have the issues he’s talking about, but maybe it’s because I have only used iPad Pro’s or iPhone Plus/Max devices in recent years which have more memory.

I regularly have dozens of tabs open and only reopening a tab that hasn’t been visited in some time results in a refresh.


I have an iPad Mini (iOS 9). Two modern webpages is definitely enough to put it over the top and reload each page when you switch between them. Sometimes even a single webpage will reload for no apparent reason.

It's generally true that memory issues seem to go away if you throw enough extra RAM at it.

Similarly, I recently upgraded from a GT120 (0.5GB) to an RX580 (8GB), and miraculously, my Mac no longer crashes when I switch spaces quickly.


He clearly meant the swap file.


I honestly haven't seen this behavior in a while in iOS, yes it used to happen all the time and I have lost a lot of mid edit posts, I used to copy the text to the clipboard before switching tabs because of it.

I guess I assumed they did something using the bfcache and serializing page state to disk in newer iOS if needed but perhaps my newer device just have more ram than before?


This is pretty annoying behavior. I'm wondering if websites can save drafts to session storage as a workaround?


> and completely forget about being nice software.

So you think thrashing is nice? I find that difficult to believe.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: