Yes, but various things that require relocations may not be. That can include code, but definitely includes data like C++ vtables, as a simple example. Just to put a number to this, for Firefox that is several megabytes per process for vtables, after some work aimed at reducing the number.
There are ways to deal with that by using embryo processes and forking (hence after relocations) instead of starting the process directly; you end up with slightly less effective ASLR, since the forking happens after ASLR.
> So what memory pressure is "exploded"?
Caches, say. Again as a concrete example, on Mac the OS font library (CoreText) has a multi-megabyte glyph cache that is per-process. Assuming you do your text painting directly in the web renderer process (which is an assumption that is getting revisited as a result of this problem), you now end up with multiple copies of this glyph cache. And since it's in a system library, you can't easily share it (even if you ignore the complication about it not being readonly data, since it's a cache).
Just to make the numbers clear, the number of distinct origins on a "typical" web page is in the dozens because of all the ads. So a 3MB per-process overhead corresponds to something like an extra 100MB of RAM usage...
Yes, but various things that require relocations may not be. That can include code, but definitely includes data like C++ vtables, as a simple example. Just to put a number to this, for Firefox that is several megabytes per process for vtables, after some work aimed at reducing the number.
There are ways to deal with that by using embryo processes and forking (hence after relocations) instead of starting the process directly; you end up with slightly less effective ASLR, since the forking happens after ASLR.
> So what memory pressure is "exploded"?
Caches, say. Again as a concrete example, on Mac the OS font library (CoreText) has a multi-megabyte glyph cache that is per-process. Assuming you do your text painting directly in the web renderer process (which is an assumption that is getting revisited as a result of this problem), you now end up with multiple copies of this glyph cache. And since it's in a system library, you can't easily share it (even if you ignore the complication about it not being readonly data, since it's a cache).
Just to make the numbers clear, the number of distinct origins on a "typical" web page is in the dozens because of all the ads. So a 3MB per-process overhead corresponds to something like an extra 100MB of RAM usage...