On Tue, May 31, 2011 at 03:28:11PM -0500, Amit Kulkarni wrote: > >> > basically rewriting the memory > >> > management part of the OS in your browser. > >> > >> Do some browsers do this on OpenBSD?
Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination logic. It even has its own code to map files in. However, the managed to avoid the common pitfall of requiring all platforms to have 4 kB pages: they hardcoded to 8 kB instead. They actually managed to create their own VM inside the browser, running on top of our VM and being almost as complex. Chrome are the ones that use 32-bit relative pointers, I doubt I need to explain how that fails on 64-bit... But hey, it's fast. Webkit allocates 2 GB at startup. Within that area, it will do its own memory management for the JIT. They also use 32-bit relative addressing. Firefox uses the unused bits in your pointer to store some tags there. Because on 64-bit computers we have all these bits, but only 48 are used. So we can store 16 bit worth of data, for free! Ofcourse, your address randomization will be friendly enough to pick memory close to the base of your memory, so of those 48 bits, only 34 are really in use... Oh, you wouldn't believe how starved for memory we are on those pesky 64-bit computers! > > Of course they do, otherwise they wouldn't run at all. > > > > google for MAP_32BIT. > > > > Once you've read enough to get sick to your stomach, please realize > > that this is just the tip of the iceberg. > > I am guessing there's nothing special about OpenBSD, they would > probably be doing it everywhere. Then they lie about being truly 64 > bit. When a developer writes a piece of code and that code breaks stuff, the developer gets blamed. Often rightfully so, but sometimes the code only exposes a bug elsewhere. Linux, windows, apple, they all make their memory management behave in certain ways to make these browsers work. When the OS stops the browser from working, people will complain until the OS stops breaking the browser. > The recent trend of forking another process for a tab instead of a > monolithic single process for the whole browser is a way of extending > the time required to clean up this mess? Or there is no relation > between them? I cannot look into the heads of the chrome devs. There's no technical reason why the tabs can't run in the same process. There's even no technical need to have them run in separate threads (although it does simplify some things). The separate processes do mean each JIT will have its personal 2GB, without competing with other tabs. So yeah, it could be related. > Wow... didn't know this. I heard this somewhere: A man visits the doctor, saying "if I do this, it hurts". To which the doctor replies "then don't do that". We now have a situation where we say it hurts. The people behind mozilla, chrome v8, webkit (and so much more software) get to play doctor. Will they fix it or tell us not to do that? -- Ariane
