WebKit2 SharedSecondaryProcess model
Hi all! I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that. Cheers! Balazs Kelemen
Hi Balazs, Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles. -Sam On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb@inf.u-szeged.hu> wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
(Sorry for flooding the list but I need to repeat my reply to put it in the right thread.) Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). Please provide some feedback on this because it is important for our project to know which way should we go on with WebKit2. Thank you! Balazs Kelemen On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb@inf.u-szeged.hu <mailto:kb@inf.u-szeged.hu>> wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi! Just to get things clear: SecondaryProcessModel: Web processes: {W} {W} {W} {W} {W} | | | | | UI processes: {<t> <t> <t>} {<t> <t>} This should be the model Chrome uses, and the model which saves some memory and is parallel should be the SharedSecondaryProcessModel: Web processes: {W} {W} / | \ / \ UI processes: {<t> <t> <t>} {<t> <t>} where <t> means the tabs (or pages) and {<t>} represents a process with one tab. Balazs, the model you suggested, would look like: SharedSecondaryServerProcessModel (maybe): Web proces (server): {W} /// \\ UI processes: {<t> <t> <t>} {<t> <t>} Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets. I see that this model is not really parallel, but saves memory. Is there a future plan to support this model too? BR: Andras On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
(Sorry for flooding the list but I need to repeat my reply to put it in the right thread.)
Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). Please provide some feedback on this because it is important for our project to know which way should we go on with WebKit2. Thank you!
Balazs Kelemen
On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb@inf.u-szeged.hu <mailto:kb@inf.u-szeged.hu>> wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
----------------------------------------
Date: Fri, 3 Sep 2010 15:11:29 +0200 From: abecsi@inf.u-szeged.hu To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] WebKit2 SharedSecondaryProcess model
Hi!
Just to get things clear:
At risk of getting too simplistic, it may help to talk about what a process even means- do you actually mean process or instance? That is, a given instance of W talks only to some set of t's and it executes in slices based on OS threading ? In terms of code, you can imagine two ways to communicate: memory and sockets(or maybe a platform specific thing that acts like one). The former being fast assuming VM and cache are not trashed while the latter allows for pieces to be anywhere. On phone or anywhere really, it helps to have someone who has a global view of resource usage - again memory and IO come to mind. It should not be difficult, say, to add a local caching proxy into the "W" and have every tab use it without having to cache the same image per-tab. Further, memory coherence and even various warning (" this script is slowing things down" is common) need to have someway to monitor who is using what ( the slow script example need not have a global view of things but let's say someone wants to open a new page and wants to prompt user to "shutdown foo to make things better"). I guess if you made various code groups that shared memory with perhaps multiple threads and isolated them with some abstract "communictor" classes that these classes could be either just interface classes that more or less inline or complicated socket code that interacts with the "W" classes to allow for distributed browsing. This thinking could even help memory coherence if you thought about pre-allocating a big block based on size estimates for the specific task. This task specific block would then be a contiguous area that the allocs for that task would reference.
SecondaryProcessModel:
Web processes: {W} {W} {W} {W} {W} | | | | | UI processes: { } { }
This should be the model Chrome uses, and the model which saves some memory and is parallel should be the
SharedSecondaryProcessModel:
Web processes: {W} {W} / | \ / \ UI processes: { } { }
where means the tabs (or pages) and {} represents a process with one tab.
Balazs, the model you suggested, would look like:
SharedSecondaryServerProcessModel (maybe):
Web proces (server): {W} /// \\ UI processes: { } { }
Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets. I see that this model is not really parallel, but saves memory.
Is there a future plan to support this model too?
BR: Andras
On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
(Sorry for flooding the list but I need to repeat my reply to put it in the right thread.)
Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). Please provide some feedback on this because it is important for our project to know which way should we go on with WebKit2. Thank you!
Balazs Kelemen
On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen
wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets.
Exactly, that is my idea.
Is there a future plan to support this model too?
At least in my mind it is :) . It would increase the complexity of the framework of course, so it would be important to know other's opinion from the community.
Hi, Sorry for the tardy reply. We currently have no plan to support that model, but it will be something we can keep in mind as we progress. I would like us to concentrate on getting the simple two-process case (SharedSecondaryProcessModel) working well, before we get more adventurous. -Sam On Fri, Sep 3, 2010 at 6:11 AM, Andras Becsi <abecsi@inf.u-szeged.hu> wrote:
Hi!
Just to get things clear:
SecondaryProcessModel:
Web processes: {W} {W} {W} {W} {W} | | | | | UI processes: {<t> <t> <t>} {<t> <t>}
This should be the model Chrome uses, and the model which saves some memory and is parallel should be the
SharedSecondaryProcessModel:
Web processes: {W} {W} / | \ / \ UI processes: {<t> <t> <t>} {<t> <t>}
where <t> means the tabs (or pages) and {<t>} represents a process with one tab.
Balazs, the model you suggested, would look like:
SharedSecondaryServerProcessModel (maybe):
Web proces (server): {W} /// \\ UI processes: {<t> <t> <t>} {<t> <t>}
Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets. I see that this model is not really parallel, but saves memory.
Is there a future plan to support this model too?
BR: Andras
On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
(Sorry for flooding the list but I need to repeat my reply to put it in the right thread.)
Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). Please provide some feedback on this because it is important for our project to know which way should we go on with WebKit2. Thank you!
Balazs Kelemen
On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb@inf.u-szeged.hu <mailto:kb@inf.u-szeged.hu>> wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Sep 3, 2010 at 6:41 PM, Andras Becsi <abecsi@inf.u-szeged.hu> wrote:
Hi!
Just to get things clear:
SecondaryProcessModel:
Web processes: {W} {W} {W} {W} {W} | | | | | UI processes: {<t> <t> <t>} {<t> <t>}
This should be the model Chrome uses, and the model which saves some memory and is parallel should be the
SharedSecondaryProcessModel:
Web processes: {W} {W} / | \ / \ UI processes: {<t> <t> <t>} {<t> <t>}
where <t> means the tabs (or pages) and {<t>} represents a process with one tab.
Balazs, the model you suggested, would look like:
SharedSecondaryServerProcessModel (maybe):
Web proces (server): {W} /// \\ UI processes: {<t> <t> <t>} {<t> <t>}
Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets.
Doesnt this model have the drawback of slowing down the response when servicing multiple clients and even bringing down the system with a faulty content which is the major plus in other models. Given this, the slightly extra memory in other models is a good tradeoff IMO (even embedded devices have large memory these days).
I see that this model is not really parallel, but saves memory.
Is there a future plan to support this model too?
BR: Andras
On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
(Sorry for flooding the list but I need to repeat my reply to put it in the right thread.)
Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). Please provide some feedback on this because it is important for our project to know which way should we go on with WebKit2. Thank you!
Balazs Kelemen
On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb@inf.u-szeged.hu <mailto:kb@inf.u-szeged.hu>> wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that.
Cheers! Balazs Kelemen _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Doesnt this model have the drawback of slowing down the response when servicing multiple clients and even bringing down the system with a faulty content which is the major plus in other models. Given this, the slightly extra memory in other models is a good tradeoff IMO (even embedded devices have large memory these days).
Yes, it could decrease responsiveness. We would sacrifice performance for memory with this model. It would be useful mostly for flyweight applications and widgets that do not need very high responsiveness and has smaller workload for the web engine then starting and initializing a web process. It is also true that if the singleton instance of the web process crashes then all the client processes became broken. However it would be possible to running plugins in separate processes. It is important to note that this model can leave together with the others. Applications could chose the model they want to use.
participants (6)
-
Andras Becsi
-
Balazs Kelemen
-
kb＠inf.u-szeged.hu
-
Mike Marchywka
-
Sam Weinig
-
Zaheer