CSP and Isolates

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Doug wrote:

> While I'm at it, I should mention that JSR121 (See http://jcp.org) is
> also of interest to this group. It will introduce (probably not until
> release 1.5) a new lightweight process-like entity, tentatively called
> an "Isolate", that runs in a separate "address space" than any other
> thread. It shares JVM resources, but no programmer-accessible
> resources (so, no shared variables).  So you will finally be able to
> get process-style semantics in Java without starting up a new JVM,
> although it will be extremely challenging to make these lightweight
> enough to be used as CSP-style processes in typical CSP-style
> designs. Communication across Isolates can be achieved via RMI, and
> possibly other mechanisms.

As I understand it, the purpose of these "Isolate"s is to enable many
applications to be loaded - and managed - on machines with memory
footprints and processor power too small to afford separate JVMs for
each application ... JVMs being memory hungry and OS switching between
JVM tasks expensive.  They daren't risk running the applications as
separate Threads within the same JVM because of the danger of accidental
side-effect (since we can't stop them sharing objects - e.g. static
class attributes).  Separate ClassLoaders, while preventing some of
this sharing, do not eliminate all problems.

So, Isolates are concurrent applications running within a single JVM
(and single memory space) but which cannot share objects (i.e. if one
Isolate holds an object reference, no other Isolate holds it).  Object
reference ownership is static between Isolates - they are not MOBILE
(i.e. one Isolate cannot give one of its objects to another Isolate),
although that would be a rather good idea!  Communication between
Isolates, if it happens at all, happens like communication between
JVMs - by deep copying using an RMI API (or even CSP channels!).

Isolates share a similar API (and semantics) to Threads.  They are
concurrent threads of control ... but things are arranged so that they
cannot see each others' objects.  There are the usual start/join/run
methods ... but also now non-deprecated stop/suspend/resume ones.  This
is to allow the creator of those Isolates to manage them - e.g. to zap
them whenever it pleases.  Because, they don't share data or have
any synchronisations in common, the problems with stop/suspend/resume
on ordinary Threads don't arise.  For some reason, Isolates do not
support an Interrupt operation (which is safe for Threads) - is this
an oversight (Doug)?  It would seem a reasonable thing a manager might
want to do.

Observation: I have problems from Windows applications interfering with
each other anyway.  I suspect these are race hazards arising from foolishly
starting them up in parallel (too rapid double-clicking) as they compete for
resources - like the network or disk - without bothering to synchronise?
But they can lock up anyway at unpredictable (and unrepeatable) times,
which may be due to internal errors or - maybe - interference between
applications ... who knows?

Question: if there are interference problems between separate Windows tasks,
why should I have confidence that there won't be interference problems
between Isolates?  I guess the answer is that it's because it's the JVM
that's managing them - not Windows.  But who's managing the JVM?

So, yes, these Isolates have some characteristics of some CSP designs -
they don't share memory and they (can) communicate, though only by deep
copying.  And it is an interesting (and medium-term?) challenge to develop
JVMs that can manage this in a light enough way to make them attractive.

But we want much more than this.  We want shared-memory concurrency and CSP
locking mechanisms for control - see previous posting.  And we definitely
want to be able to take advantage of MOBILE communications, rather than
deep copying.  To do this, though, requires a language that takes aliasing
problems seriously.

If we could really combine CSP ideas with dynamic allocation off a shared
heap, then we wouldn't need these Isolates.  Processes would be automatically
invulnerable to sharing accidents and there would be no problems in managing
multiple applications in the same VM.  There would be no logical or run-time
difference between different applications and concurrent processes within
the same application - and we would have the same freedom from uncaught race
hazards and deadlock within applications as between them (and Isolates only
address the latter).

If we built the operating system as a collection of CSP processes, dynamically
linked in as needed in the same way as application processes, and managed the
whole lot with something akin to the occam kernel ... so that system processes
and application processes interoperate with the same (CSP) model and the same
(nanosecond) overheads ... :) :) :) ...

Well, we had all this 17 years ago with the transputer ... think what we could
do now ...

Peter.