why isolated components

[Joe Armstrong]

On Thu, 21 Aug 2003, Joachim Durchholz wrote:

> Laszlo Varga wrote:
> > Really, why?
> > What are the (main) motivations for kind a system?
> 
> Let me rephrase, in the hopes that I understood your question correctly:
> What is the main motivation for isolating components?
> 
> The answer is simple. If you double the number of names in a program, 
> the number of unwanted possible interaction quadruples. More generally, 
> for N items, you have N*(N-1)/2 possible interactions.
> ... cut ...

  Nicely put.

  I  must admit  that when  I read  the question  I had  thought  of a
*completely different* answer - so I you mail quite surprised me, I've
been thinking upon different lines :-)

  Why isolated components?

	- for fault isolation
	- for concurrency/scalability

  My  main reason  for wanting  isolated components  is  for isolating
software faults in the components themselves.

  Virtually all  software contains  faults. In a  system with  lots of
things happening  at the  same time  I don't want  faults in  a faulty
component  to effect  the behaviour  of  a component  that is  running
somewhere else in the system.

  Normally we use  OS processes for precisely this  reason - processes
provide "protection domains"  and the isolate the effects  on an error
to the process where the error occurred.

  At least that's the  idea - no OS that I know  of has this property,
and  some OSs  are better  than others.   Windows 98  for  example has
appalling protection between processes  - doing something silly in one
process can easily crash the  entire machine. The Linuxes are not much
better - one process can essentially  do a denial of survive attack on
other processes in the system, by thrashing the disk or something.

  Processes running on *isolated* machines  are much better.  If I run
one  process  in Sweden  and  another  in the  USA  and  if they  only
communicate asynchronously it becomes more unlikely that a SW error in
the Swedish machine will crash the process running on a machine in the
USA.

  Two processes running on the  same machines should be as independent
as if they ran one two machines in different countries.

  Modern OSs try to achieve this but fail.

  Erlang tries to achieve this, it does somewhat better than mosts OSs
but  still one  process could  attack  another process  by sending  it
zillions of  messages. Erlang was  designed to protect  processes from
accidental errors not malicious attack.

  It is precisely the lack of protection between processes that makes,
for example, Java unsuitable for  large-scale SW projects. This is not
my  conclusion but  is the  conclusion  draw by  researchers from  Sun
Labs. Let me quote:

<begin quote>

In a paper on Java by Czajkowski and Dayn\`{e}s [1], from Sun
Microsystems, say:

  The only safe  way to execute multiple applications,  written in the
Java programming language,  on the same computer is  to use a separate
JVM  for each  of  them, and  to execute  each  JVM in  a separate  OS
process.    This  introduces   various   inefficiencies  in   resource
utilization,   which    downgrades   performance,   scalability,   and
application startup time. The benefits the language can offer are thus
reduced  mainly to portability  and improved  programmer productivity.
Granted   these   are   important,   but   the   full   potential   of
language-provided  safety is  not  realized.  Instead  there exists  a
curious distinction between ``language safety'' and ``real safety''.


  In  their paper they  introduce the  MVM (an  extension to  the JVM)
their goal is:

  ... to turn the JVM into  an execution environment akin to an OS. In
particular, the abstraction  of a process, offered by  modern OSes, is
the   role  model  in   terms  of   features;  isolation   from  other
computations,  resources  accountability  and  control,  and  ease  of
termination and resource reclamation.

  To achieve  this they  conclude that:

  ... tasks cannot  directly share objects, and that  the only way for
tasks  to  communicate  is  to  use  standard,  copying  communication
mechanisms

<end quote>

The full paper is very interesting - they say

1) Java is not a safe language
2) Java applications cannot me mixed in the same JVM
3) Java threads do not offer the protection offered by OS threads

  Then they invent Erlang :-) (joke)

  I mailed  C & D  and asked how  the MVM was  going - whey  said they
could have  a max  of 125  parallel JVMs going  at once  (compare with
hundred of thousands of Erlang processes) and the JVM "spawn" time was
not microseconds but "as lot as it  took to start a regular JVM" - wow
- don't hold your breath.

  Software  development goes  fine  until somebody  gets  the idea  of
linking together different bits of code into the same memory space and
allowing  languages  which  can  overwrite  not you  own  memory,  but
somebody else's memory.

  OS processes  basically give  you resource protection  + concurrency
the main resource being memory.

  Memory protection  is *unnecessary*  in a language  without pointers
and decent  garbage collector  (like Erlang, lisp,  prolog, smalltalk,
...)  but essential for C, C++.

-----------------------------------------------------------------------

  My second reason for isolated components has to do with concurrency,
scalability etc. If components are NOT isolated, or cannot be isolated,
then the system  is NOT scalable - the code  must be re-written before
it can be scaled.

  If two  sub-components A and B  are assembled together to  form C in
such  a way that  A and  B are  not strictly  isolated with  a message
passing  channel  between  them   then  scaling  or  distributing  the
application will be difficult or impossible.

  If A and B are isolated then we can easily run A and B on the *same*
machine  OR   on  *different*  machines   -  this  is  the   basis  of
fault-tolerance, scalability etc.

-----------------------------------------------------------------------

Long live isolated components with asynchronous streams :-)

Isolation is an essential pre-condition for building 
fault-tolerent systems.

/Joe

Refs

[1]

@inproceedings{javaProcesses,
 author = {Grzegorz Czajkowski and Laurent Dayn\`{e}s},
 title = {Multitasking without comprimise: a virtual machine evolution},
 booktitle = {Proceedings of the OOPSLA '01 conference on Object Oriented Programming Systems Languages and Applications},
 year = {2001},
 isbn = {1-58113-441-X},
 pages = {125--138},
 location = {Tampa Bay, FL, USA},
 doi = {http://doi.acm.org/10.1145/504282.504292},
 publisher = {ACM Press},
 }