4 ms·

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

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.

rayiner 7y ago
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.
- asdfasgasdgasdg 7y ago
  As the fine article tells, there is no swap on iOS. It sounds like a great solution for the case where there is swap.
vbezhenar 7y ago
Most of these resources should be easy to recreate. Basically you need to save DOM, JavaScript objects, things like timers. It should be possible.
- olliej 7y ago
  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.
  - vbezhenar 7y ago
    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.
    - olliej 7y ago
      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.

rayiner 7y ago

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.

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

vbezhenar 7y ago

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

olliej 7y ago
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.
- vbezhenar 7y ago
  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.
  - olliej 7y ago
    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.