[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