On Tue, May 26, 2009 at 1:06 PM, Adam Langley <[email protected]> wrote: > But we've gone over this before? Zygotes disable ASLR, make debugging harder > etc. They might have some performance benefits, but I don't believe that > they're the correct solution for the auto update issue.
I suggested Dan bring this up on chromium-dev so we could hash it out publicly. :) (For context for the rest of the list: the question is whether we re-fork a preforked "zygote" renderer subprocess or do a new fork/exec of our binary when we want a new renderer process.) Here's a list of the issues I've heard about. ASLR: you say it disables ASLR, but it seems you get whatever randomized address space the initial zygote got. Net effect is that within a given browser instance each renderer will have the same layout. How bad is that? (Honest question, not suggesting it isn't bad.) Debugging: you say it's harder, but I'm not sure why. Because of the renderer-cmd-prefix stuff? But gdb is just as capable of attaching to a pid -- rather than --renderer-cmd-prefix='xterm -e gdb' we could just as well do --renderer-cmd-pid-prefix='xterm -e gdb -p'. On the pro-zygote side, issues we have: Updates clobbering our files. If we open everything before we fork we're good. (I'm not confident that we can open everything we want before we fork -- the inspector is a collection of random files scattered in /usr/share. But the inspector problem applies to any solution I've yet seen and we ought to be able to pack it into one mmappable file if we want.) Sharing: with zygotes, each instance of webkit shares memory pages, even the ones we tweak after renderer startup but before we fork. Performance: may be faster to start renderers if we've preforked. Sharing/performance of course don't count as benefits until we have numbers to support them. Dan did preliminary measurements and found no perf win, but I don't know if we have tests that measure the performance of starting many tabs. > However, we could easily make a hardlink with a specific version in the name. > That could go wrong if packaging systems write the same inode when updating > rather than creating a new one, but I suspect that they don't. A patch to use > the zygote hammer for the auto-updating issue would first have to show that > there's no easier alternatives! I don't have a strong opinion on what we should do here beyond "right now we're broken and we should fix that". We can imagine many solutions but each time there's a bit of hand-waving. Perhaps you could make a concrete counterproposal? (Again, I don't mean that to sound as hostile as it might seem -- I honestly think it'd be good to be able to weigh pros/cons of approaches.) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
