Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 10:18 PM, Fady Samuel fadysam...@gmail.com wrote: Which brings me back to the original topic of replicated state. Is there any reason not to have a single monolithic cache (or other similar state) across all processes other than synchronization issues or fault tolerance? If chromium ever achieves process separation for origin security, then a shared monolithic cache would probably be a bad idea. I have a technique to give me a consistent, snapshot view of data structures without actually creating a copy of the data structure (a form of concurrent, robust iterator I'm calling a strongly consistent iterator). The shared data structure itself can also be made fault tolerant despite being shared. That way, two site instances can share images, scripts, etc. Thanks, Fady On Thu, Jan 7, 2010 at 4:49 PM, James Robinson jam...@google.com wrote: There's a group at UC Berkeley that was (is?) working on a similar idea, you can read about it here: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/With a discussion that happened a few months back here: http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.htmlFrom the discussion on webkit-dev I think the consensus was that it looked interesting but that it wasn't clear that any practical benefit to be gained in the short term. There's probably simpler parallelism problems in the Chromium codebase to tackle than those directly involving core layout and rendering code, perhaps some of the caching layers. - James On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel fadysam...@gmail.com wrote: Well you can't know the precise set of locks you need obviously without solving the halting problem. But maybe a static analysis can give you a conservative set of DOM trees you might access. Sorry, just thinking out loud I guess. Fady On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis cr...@chromium.org wrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.comwrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
You could partition a monolithic cache by origin or site (to prevent cache timing attacks) and still get a reduced memory footprint. If Fady's able to to work out the consistency issues, it'd be nice to only have one in-memory cache for all my google.com tabs, etc. I bet there's a lot of cases where the same site shows up in many processes, even with strict site isolation, since we isolate each independent instance of the site. Charlie On Fri, Jan 8, 2010 at 7:26 AM, Ben Laurie b...@google.com wrote: On Thu, Jan 7, 2010 at 10:18 PM, Fady Samuel fadysam...@gmail.com wrote: Which brings me back to the original topic of replicated state. Is there any reason not to have a single monolithic cache (or other similar state) across all processes other than synchronization issues or fault tolerance? If chromium ever achieves process separation for origin security, then a shared monolithic cache would probably be a bad idea. I have a technique to give me a consistent, snapshot view of data structures without actually creating a copy of the data structure (a form of concurrent, robust iterator I'm calling a strongly consistent iterator). The shared data structure itself can also be made fault tolerant despite being shared. That way, two site instances can share images, scripts, etc. Thanks, Fady On Thu, Jan 7, 2010 at 4:49 PM, James Robinson jam...@google.com wrote: There's a group at UC Berkeley that was (is?) working on a similar idea, you can read about it here: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/With a discussion that happened a few months back here: http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.htmlFrom the discussion on webkit-dev I think the consensus was that it looked interesting but that it wasn't clear that any practical benefit to be gained in the short term. There's probably simpler parallelism problems in the Chromium codebase to tackle than those directly involving core layout and rendering code, perhaps some of the caching layers. - James On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel fadysam...@gmail.comwrote: Well you can't know the precise set of locks you need obviously without solving the halting problem. But maybe a static analysis can give you a conservative set of DOM trees you might access. Sorry, just thinking out loud I guess. Fady On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis cr...@chromium.orgwrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.comwrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 12:43 PM, Fady Samuel fadysam...@gmail.com wrote: Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). That's correct - there is no notion of multithreading or concurrency in the JavaScript language, and no locking primitives. If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. No, you can't interleave execution between different pieces of JavaScript in the same context at all (at least, you can't let any JavaScript observe that you are doing so - and since so much JavaScript touches the global object this boils down to the same thing). JavaScript has a fairly simple run-to-completion model. - James Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote: Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Javascript absolutely expects to be single-threaded, and Javascript programmers expect it even more so. Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote: On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote: Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Javascript absolutely expects to be single-threaded, and Javascript programmers expect it even more so. That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis cr...@chromium.org wrote: On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote: On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote: Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Javascript absolutely expects to be single-threaded, and Javascript programmers expect it even more so. That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. There are 2 exceptions in Chrome and IE (and maybe Opera?): Cookies and LocalStorage. The spec attempts to solve both of these with a Storage Mutex which basically must be taken on the first access to a cookie or localStorage and must not be released until the current script execution ends. The network stack is also supposed to take this lock when reading or writing cookies. The single mutex is shared across the entire browser. A LOT of time and effort has been spent on coming up with a better answer, but there are a lot of constraints to the problem (not all of them technical) and I've pretty much given up hope of anything better replacing it in the spec. That said, we have no intention of being the first to implement the storage mutex in Chrome, and I know of no one else intending to implement it either. So until then, cookie and localStorage access is simply racy (in Chrome, IE, and maybe Opera). Charlie Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.orgwrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA
Re: [chromium-dev] Replicated State among tabs in Chromium
What about allowing the renderer to run asynchronously with the script? Right now you're either producing the view or you're running script but never both concurrently, correct? Parallelizing them should not introduce issues I think (assuming the renderer has the equivalent of a snapshot view of the DOM tree)? Fady On Thu, Jan 7, 2010 at 4:10 PM, Charlie Reis cr...@chromium.org wrote: On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote: On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote: Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures. A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be awesome. Javascript absolutely expects to be single-threaded, and Javascript programmers expect it even more so. That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie Thanks, Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.orgwrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list:
Re: [chromium-dev] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 1:30 PM, Fady Samuel fadysam...@gmail.com wrote: What about allowing the renderer to run asynchronously with the script? Right now you're either producing the view or you're running script but never both concurrently, correct? Parallelizing them should not introduce issues I think (assuming the renderer has the equivalent of a snapshot view of the DOM tree)? But the chief use of JS is to manipulate the DOM. There's little real parallelism to extract there, and great cost to doing so. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.com wrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Well you can't know the precise set of locks you need obviously without solving the halting problem. But maybe a static analysis can give you a conservative set of DOM trees you might access. Sorry, just thinking out loud I guess. Fady On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis cr...@chromium.org wrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.com wrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
And before you suggest using software transactional memory, keep in mind that side effects (XHRs and other network activity for example) are prevalent in normal JavaScript usage. I don't mean to discourage you too muchespecially if you were interested in digging really deeply into this stuff...but I can assure you that a lot of the more obvious, high level solutions to this stuff have been explored many times over. I think some of the more focused uses within specific implementations might be a better place to start. On Thu, Jan 7, 2010 at 1:36 PM, Charlie Reis cr...@chromium.org wrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.com wrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
There's a group at UC Berkeley that was (is?) working on a similar idea, you can read about it here: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/With a discussion that happened a few months back here: http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.htmlFrom the discussion on webkit-dev I think the consensus was that it looked interesting but that it wasn't clear that any practical benefit to be gained in the short term. There's probably simpler parallelism problems in the Chromium codebase to tackle than those directly involving core layout and rendering code, perhaps some of the caching layers. - James On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel fadysam...@gmail.com wrote: Well you can't know the precise set of locks you need obviously without solving the halting problem. But maybe a static analysis can give you a conservative set of DOM trees you might access. Sorry, just thinking out loud I guess. Fady On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis cr...@chromium.org wrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.com wrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Which brings me back to the original topic of replicated state. Is there any reason not to have a single monolithic cache (or other similar state) across all processes other than synchronization issues or fault tolerance? I have a technique to give me a consistent, snapshot view of data structures without actually creating a copy of the data structure (a form of concurrent, robust iterator I'm calling a strongly consistent iterator). The shared data structure itself can also be made fault tolerant despite being shared. That way, two site instances can share images, scripts, etc. Thanks, Fady On Thu, Jan 7, 2010 at 4:49 PM, James Robinson jam...@google.com wrote: There's a group at UC Berkeley that was (is?) working on a similar idea, you can read about it here: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/With a discussion that happened a few months back here: http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.htmlFrom the discussion on webkit-dev I think the consensus was that it looked interesting but that it wasn't clear that any practical benefit to be gained in the short term. There's probably simpler parallelism problems in the Chromium codebase to tackle than those directly involving core layout and rendering code, perhaps some of the caching layers. - James On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel fadysam...@gmail.com wrote: Well you can't know the precise set of locks you need obviously without solving the halting problem. But maybe a static analysis can give you a conservative set of DOM trees you might access. Sorry, just thinking out loud I guess. Fady On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis cr...@chromium.org wrote: The catch is that you don't know what locks you need to acquire in advance, especially in the presence of things like eval. (And of course, you can't roll back any JavaScript you've already run, so you would need to know the locks in advance.) Charlie On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel fadysam...@gmail.comwrote: Hmm, I wonder if strict two-phase locking can be here to solve this? Fady That's correct. However, Fady is referring to an observation in my paper that race conditions are actually possible in cross-window JavaScript calls in Internet Explorer and Opera. Those browsers allow pages in different windows to run in separate threads, even if they are from the same site and can easily call into each other. From my tests, it appears that IE at least tries to avoid race conditions by blocking one page until the other finishes, but it allows the race if a deadlock occurs. You can test this fairly easily by calling a long-running function in another page that is repeatedly calling the function itself. In Opera, both pages' threads will be in the function at once. In IE, the first page will be blocked until the second finishes, unless the second page tries to call back into the first page at the end of its function. That would be a deadlock, so instead they allow the data race. I don't think the spec allows for these races-- as people have mentioned, JavaScript has a single-threaded, run-to-completion model. Chromium avoids races by only putting pages that can't communicate on different threads/processes. Charlie -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Perhaps a silly question but what about plugins? Charlie mentioned in his paper that plugins run in a separate process. Does the renderer also respond to draw requests from plugins such as Flash? So by running the renderer asynchronously from script, maybe one can allow it to respond more rapidly to plugins? Faster Flash perhaps? Fady On Thu, Jan 7, 2010 at 4:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 7, 2010 at 1:30 PM, Fady Samuel fadysam...@gmail.com wrote: What about allowing the renderer to run asynchronously with the script? Right now you're either producing the view or you're running script but never both concurrently, correct? Parallelizing them should not introduce issues I think (assuming the renderer has the equivalent of a snapshot view of the DOM tree)? But the chief use of JS is to manipulate the DOM. There's little real parallelism to extract there, and great cost to doing so. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. -Darin On Mon, Jan 4, 2010 at 4:43 PM, Fady Samuel fadysam...@gmail.com wrote: Hello all, I'm interested in looking into replicated state between processes in Chromium to try to share more of that state and help reduce Chromium's memory footprint. I am unfamiliar with the Chromium source at this point in time, so I would appreciate if someone would point me to the problem areas to investigate. Thanks, Fady -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 4:58 PM, Darin Fisher da...@chromium.org wrote: There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. If you look into this, note that there are major tricky issues here around synchronization if you start trying to share caches between processes without hammering perf. Also, the gain from sharing these will not necessarily be large, for two reasons: * We already set a fairly small global size limit for the sum of all resource caches (and the other caches are pretty trivial) * Renderers in separate processes are very likely to be on separate sites and have mostly disjoint cacheable sets PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Peter, I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. Thanks, Fady On Mon, Jan 4, 2010 at 8:02 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 4:58 PM, Darin Fisher da...@chromium.org wrote: There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. If you look into this, note that there are major tricky issues here around synchronization if you start trying to share caches between processes without hammering perf. Also, the gain from sharing these will not necessarily be large, for two reasons: * We already set a fairly small global size limit for the sum of all resource caches (and the other caches are pretty trivial) * Renderers in separate processes are very likely to be on separate sites and have mostly disjoint cacheable sets PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. I'm not aware of anything that really falls into this category. We share the visited link state but use a carefully-designed system to avoid excessive locking. Renderers can share bitmaps with the browser via shared memory, but there isn't contention here that I'm aware of. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:48 PM, Fady Samuel fadysam...@gmail.com wrote: So as Peter said a lot of this cache state will not be used in multiple tabs because many of these tabs will be different webpages. That's not to say that one doesn't open multiple pages from a single site however, in which case the image cache might have a lot replication overhead. However, opening multiple pages from a single site will usually also lead to those pages being in the same process (depending on how they were opened). PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Thanks Adam, So as Peter said a lot of this cache state will not be used in multiple tabs because many of these tabs will be different webpages. That's not to say that one doesn't open multiple pages from a single site however, in which case the image cache might have a lot replication overhead. I am currently watching the Painting in Chromium video. Is the font cache replicated or shared? Thanks, Fady On Mon, Jan 4, 2010 at 8:22 PM, Adam Langley a...@chromium.org wrote: On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Sorry, one last thing I would be interested in looking into: fault Tolerance of shared state. In particular, can a crashing process currently break shared data structures thus breaking the whole browser (e.g. leaving shared data structures in an inconsistent state)? Thanks, Fady On Mon, Jan 4, 2010 at 8:22 PM, Adam Langley a...@chromium.org wrote: On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
(re-adding chromium-dev) On Mon, Jan 4, 2010 at 5:58 PM, Fady Samuel fadysam...@gmail.com wrote: Was this done to reduce memory overhead? No, it was done because the newly opened pages and the original pages can script each other. From what I understand, making sites in different processes able to script each other is somewhere between very hard and impossible. Darin Fisher, Charlie Reis, Adam Barth and others know much more about this. Doesn't this introduce a fault tolerance issue? In that it increases the number of tabs affected by renderer crashes? Yes, but we don't really have a choice. That's how the web works. I believe MS' Gazelle project purposefully breaks scriptability here in order to maintain more robust separation. This pretty much breaks the web and wouldn't be shippable as a consumer browser. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 6:32 PM, Fady Samuel fadysam...@gmail.com wrote: I know I'm asking you a lot of questions here. And you keep removing chromium-dev. Why? I'm not the knowledgeable person about much of this stuff, I'm just trying to be helpful. Alex mentioned the Webkit DOM tree, indicating that making the nodes of the DOM tree immutable in this fashion would be interesting. Why? AFAIK the DOM tree isn't shared across processes, and the renderer is effectively single-threaded as far as this is concerned. How does the current traversal of the DOM tree work? Does it require locking? Do you create a copy of the tree for rendering purposes? I assume scripting enables dynamic updates of the DOM tree to happen all the time? I haven't looked into this much myself yet. How is the synchronization handled there currently? As I said, I believe the DOM tree isn't shared across processes, so there is no synchronization that I know of. I am way out of my depth in this area so you really should not ask me specifically. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
I'm not disagreeing with you. Yes, the script needs to see a coherent state as it executes BUT the renderer only needs a logically consistent snapshot, correct? So the script can work on the most current version of the DOM, while the renderer does its thing to produce a bitmap from the snapshot? Again, I may be spouting nonsense due to my ignorance of the details of the Webkit/Chromium architecture. I don't really know how the pieces fit together yet. I apologize for that. I'll spend a couple of days to better understand the architecture. Fady In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Charles, this is awesome! Thanks! Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
