[cap-talk] Domain optimisation (was: Domain change (IPC?) overhead)

John McCabe-Dansted gmatht at gmail.com
Wed Mar 26 08:54:35 EDT 2008


On Tue, Mar 25, 2008 at 4:41 AM, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> On Mon, 2008-03-24 at 11:54 -0700, Jed Donnelley wrote:
>  > On 3/24/2008 9:52 AM, Jonathan S. Shapiro wrote:
> > > However: robustness implies introducing IPC, and each IPC adds overhead.
>  > > As applications are factored and multiple layers of IPC are introduced,
>  > > performance of IPC becomes critical very quickly.
>  >
>  > Isn't the above consideration where the language systems for
>  > POLA provide significant additional value?
>
>  Not clear. Depends on what percentage of your IPCs are doing data
>  motion. If you want to avoid storage denial of service issues and keep
>  GC local to each domain, you still have a copy boundary at the domain
>  boundary, and the copy cost can get large.

OTOH, decomposing an application into different GC domains also has
the potential to improve performance, by perhaps 15%, as different
algorithms perform better under different GC mechanisms:
  http://research.microsoft.com/~dtarditi/dist/ismm-2000a.pdf

So, even from a performance point-of-view, cramming everything into
one huge unaccountable resource pool may not be optimal.

As mentioned elsewhere in the thread, from a security point-of-view it
hardly seems necessary to put every one-line function in its own GC
domain. Even on a typical oo-cap system I'd say that someone who could
social engineer a malicious module into an application could typically
do far more insidious things than crash a vat. Code that has no trust
relationship at all (e.g. random applets off the web) could still be
put in their own vat.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia


More information about the cap-talk mailing list