"on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes"
We need more information. For instance, it would be enlightening to have an understanding of how, exactly, a "real workload" is defined? How many tabs? What's going on in the tabs? Etc. A definition of "real workload" would at least allow us to compare that workload to our own typical workloads. (Which I assume would likely be different for an administrative assistant vs an executive vs a developer vs a researcher vs etc etc etc.)
Headline in alternate universe: "With the powerful computers available in the mid-late 2010s, it is now practical to browse an international web of documents, from your own home!"
Seriously - just this increase is 2x the total memory of a computer I used to browse the internet 20 years ago. People, including programmers, seriously misunderstand how amazingly powerful today's computers are, and how amazingly bloated and inefficient today's applications and websites are.
Couldn't agree more...People were creating universes with 1.44MB on floppies. Instead, Viber desktop app installer, for example, is a 133MB download, ~300MB installed and probably uses double the RAM...
Never mind a universe in 1.44MB; Elite did it in 32KB, albeit with wireframe graphics. [1]
The bloat of many current desktop apps, each with their own copy of a large-footprint GUI toolkit or rendering engine, is indeed sad by comparison. I hope this situation will change when Windows 7 and IE 11 are finally history, meaning that desktop app developers can count on the OS to provide a modern web rendering engine on all platforms.
I agree I wouldn't complain given the trade-off, but Chrome is one of the he biggest memory consumer on most people's desktops. A 10-13% increase from one of the biggest process I have running is significant.
If it's causing memory pressure on the system to the point of thrashing, sure. But is that the case or is able to react well to other RAM hungry processes on the system? Not using additional spare memory if it gives the user a better experience seems like a no-no.
Worse is worse. There is no upside to using more memory. You don't know what a given system has for memory, Chrome needs to be as efficient as possible. Chrome is even worse than before with this change. Creating an ideal situation to make Chrome fit is disingenuous.
Hopefully in time they find a way to retain safety without furthering to bloat their browser.
But there is an upside to better security. It'd be great if it was a free lunch but apparently it's not.
>Chrome needs to be as efficient as possible.
Chrome needs to make its users as happy as possible. Efficiency only matters when it starts affecting user happiness.
>Creating an ideal situation to make Chrome fit is disingenuous.
Do you know that it's an "ideal" situation rather than typical? I don't either but I also suspect Google wouldn't turn this on if it was going to negatively affect most users because they run the risk of losing market share to Safari/Firefox/Edge. I'm open to evidence to the contrary.
>Hopefully in time they find a way to retain safety without furthering to bloat their browser.
That's most likely going to be in the Intel/AMDs court.
Sure there is. Most complex systems can trade-off between memory usage and CPU. With more memory, the garbage collector doesn't have to work as hard, caches stay warm, etc.
> You don't know what a given system has for memory,
Chrome knows how much memory is available on your system, and it adapts its own memory usage based on this.
V8 is designed to push the garbage collector harder when memory usage is tighter -- reducing usage at the cost of JavaScript running a little slower.
I believe Chrome is also capable of freezing entire background tab states and saving them to disk, to be restored later when you go back to the tab. But there's no reason for it to do that if you have plenty of RAM to spare.
That's why you don't use garbage collection. Wasm or static pages only. V8 has been the worst thing to happen to the web, it made JS moderately performant. That's a terrible thing, now we have all this additional complexity thanks to Google's attempt to make the web an appstore.
Swapping to non-volatile storage? In the context of memory exhaustion I think it was reasonably clear gpp was talking about hitting virtual memory. Although these days faster SSDs make that not quite as dramatic a hit as it once was.
Honest question: The interesting question, IMHO, is not how much Chrome is affected, but how strong the impact is compared to other browsers. Do they suffer similarly? Have they found a way to avoid enlarging the memory footprint? Do they ignore the issue?
https://security.googleblog.com/2018/07/mitigating-spectre-w... says that they've been working on site isolation (one process per domain, so potentially several per tab) for many years. chrome has been multiprocess (process per tab) since day one and it took other browsers years to catch up with being multiprocess. So if other browsers decide to pursue this approach, it'll likely take them years as well. So 3 doesn't seem super unlikely to me :-/
They are not ignoring the issue, but they also do not have this mitigation in place.
Getting there will take a long time. Chrome got lucky - they've been working on this for ages, and they happened to be rolling this out right when Spectre landed.
Firefox is definitely working on this in Project Fission. Bringing down memory per process is crucial and a big focus right now. (I think getting resource sharing down to a science will also be important.)
I'm a fan of Firefox but admit Chrome has an advantage in this situation, while Firefox has had the advantage of resource sharing within the process to keep memory down. Last estimate I saw suggested over a year for it to arrive.
As an illustration of how this approach affects the landscape for all browsers, TechCrunch regularly loads 30 origins on a single page.
Don't blame Google for this. They only did what had to be done in software to fix Intel's hardware flaw. And Intel is currently willing to allow developers to fix many more such Spectre-class flaws in software just so it doesn't have to radically change its architecture.
Chrome has always been a memory hog. For example, the Intel chipset in my machine doesn't support installing more than 4Gb of memory (and I feel that it is artificial limitation to force consumers buy new Intel chipsets) and on top of that, some proprietary 32-bit operating system cannot use more than 3Gb because of so called "PCI hole" - a part of address space that is allocated for PCI devices and cannot be used for accessing memory.
I think that browser developers are making a wrong choice. They increase memory consumption for caches and similar type of data so that complicated and bloated websites work faster; I don't want that. I don't visit such sites anyway and have JS disabled so I would prefer that browser just consumes less memory. Let bloated websites be slow; they deserve it.
Won't this work become mostly irrelevant in the near future (at least for new hardward)? There is no way all affected software will implement workarounds like this and it this will have to be fixed at the hardware/CPU level in order to fully address it.
Not all software is equally affected by this, browsers are particularly affected because they have a JavaScript VM running untrusted code.
But Site Isolation has been in the works in Chrome for a long time and it brings additional protections because it means that exploiting a renderer process doesn't let you break the SOP, which means you absolutely have to break out of the renderer process to have a meaningful exploit - completely removing the renderer codebase from your trusted computing base.
Maybe Meltdown and Spectre would be a good point to stop and think if an architecture where you run arbitrary turing-complete untrusted code from multiple sources side-by-side and try to mitigate this by locking down the system is really the best direction for the web to move in.
I’m surprised that it took Spectre to get site isolation enabled. Without site isolation, an RCE allows a malicious site to violate the same origin policy even without a sandbox escape. Site isolation is a very nice defense in depth feature.
57 comments
[ 6.2 ms ] story [ 149 ms ] thread"on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes"
We need more information. For instance, it would be enlightening to have an understanding of how, exactly, a "real workload" is defined? How many tabs? What's going on in the tabs? Etc. A definition of "real workload" would at least allow us to compare that workload to our own typical workloads. (Which I assume would likely be different for an administrative assistant vs an executive vs a developer vs a researcher vs etc etc etc.)
Site isolation is a huge win.
Seriously - just this increase is 2x the total memory of a computer I used to browse the internet 20 years ago. People, including programmers, seriously misunderstand how amazingly powerful today's computers are, and how amazingly bloated and inefficient today's applications and websites are.
The bloat of many current desktop apps, each with their own copy of a large-footprint GUI toolkit or rendering engine, is indeed sad by comparison. I hope this situation will change when Windows 7 and IE 11 are finally history, meaning that desktop app developers can count on the OS to provide a modern web rendering engine on all platforms.
[1]: https://www.filfre.net/2013/12/elite/
Hopefully in time they find a way to retain safety without furthering to bloat their browser.
But there is an upside to better security. It'd be great if it was a free lunch but apparently it's not.
>Chrome needs to be as efficient as possible.
Chrome needs to make its users as happy as possible. Efficiency only matters when it starts affecting user happiness.
>Creating an ideal situation to make Chrome fit is disingenuous.
Do you know that it's an "ideal" situation rather than typical? I don't either but I also suspect Google wouldn't turn this on if it was going to negatively affect most users because they run the risk of losing market share to Safari/Firefox/Edge. I'm open to evidence to the contrary.
>Hopefully in time they find a way to retain safety without furthering to bloat their browser.
That's most likely going to be in the Intel/AMDs court.
Sure there is. Most complex systems can trade-off between memory usage and CPU. With more memory, the garbage collector doesn't have to work as hard, caches stay warm, etc.
> You don't know what a given system has for memory,
Chrome knows how much memory is available on your system, and it adapts its own memory usage based on this.
V8 is designed to push the garbage collector harder when memory usage is tighter -- reducing usage at the cost of JavaScript running a little slower.
I believe Chrome is also capable of freezing entire background tab states and saving them to disk, to be restored later when you go back to the tab. But there's no reason for it to do that if you have plenty of RAM to spare.
Google focuses very strongly on time, so I’m unsurprised that they are willing to trade space for time.
Of course it’s possible Chrome is also outright wasting space, time, or both, but I have no idea if it is to a nontrivial extent.
That's disingenuous.
Chrome is 1) more secure, but 2) less accessible.
These are separate metrics and you can't really roll them into one.
Sure, it's easy to say "of course it has happened, why wouldn't it have?", but it would be really interesting to know how it is actually being used.
This depends strongly on how many tabs you normally have open. At higher numbers Firefox tends to do much better.
(Please tell me it's not number 3!)
Getting there will take a long time. Chrome got lucky - they've been working on this for ages, and they happened to be rolling this out right when Spectre landed.
I'm a fan of Firefox but admit Chrome has an advantage in this situation, while Firefox has had the advantage of resource sharing within the process to keep memory down. Last estimate I saw suggested over a year for it to arrive.
As an illustration of how this approach affects the landscape for all browsers, TechCrunch regularly loads 30 origins on a single page.
https://chrome.google.com/webstore/detail/the-great-suspende...
I think that browser developers are making a wrong choice. They increase memory consumption for caches and similar type of data so that complicated and bloated websites work faster; I don't want that. I don't visit such sites anyway and have JS disabled so I would prefer that browser just consumes less memory. Let bloated websites be slow; they deserve it.
But Site Isolation has been in the works in Chrome for a long time and it brings additional protections because it means that exploiting a renderer process doesn't let you break the SOP, which means you absolutely have to break out of the renderer process to have a meaningful exploit - completely removing the renderer codebase from your trusted computing base.
I can't recall any another browser maker introducing a change as encompassing as the Chrome Meltdown and Spectre fix.