[Isolate-interest] Shared-memory based JavaSpace between Isolates?

[Pete Soper]

Bernhard Fastenrath <Bernhard.Fastenrath@arcor.de> said:
> The MemoryPoolMBean interface in Java 1.5 allows to monitor several 
> memory pools
> within a single VM. If isolate A and B (with memory pools MA and MB) 
> would share
> a third memory pool MS located in shared memory (allocated by shmget() 
> on unix)
> it might be easy to implement just that: objects shared between all isolates
> connected to this shared memory pool.

You can experiment with that now, using multiple instances of 
java.nio.MappedByteBuffer that each get managed by a different thread (doesn't
matter if in one or different Java programs) but that are mapped to the same 
file. Depending on your OS and hardware architecture (e.g. whether virtual or
physical addresses are cached) I think you may be able to observe some
"interesting" behavior that demonstrates the complete lack of a memory model
(not that this is wrong: I think it's fair to say that the Java specification
is absolutely silent about use of anything but file synchronization to avoid
chaos in this case and so it would be mistaken to assume that there is any
tacit contract that causes the Java Memory Model to extend into this domain
yet. And note also that nio provides the "force" method specifically to
ensure coherence, its just that this presume some other synchronization
scheme to know when it should be used.).

> By the way: Is there a major difference between starting several VMs 
> with Class data sharing (CDS)
> enabled and having several Isolates within the same VM (except for the 
> messaging facilities provided
> between Isolates)? If not, the Isolate specification might as well be 
> implemented as a native library
> for shared memory access.

Class data sharing is orthogonal to the isolation APIs but relates to their
implementations; some might provide greater or lesser amounts of sharing of 
class data or other metadata than is offered by the J2SE 1.5 class sharing
feature. There might also be differences in restrictions like which class
paths fall within the metadata sharing and as mentioned in the past there is
really a spectrum of sharing possible such that the traditional definition of
JVM can become very blurry or remain sharp or fall somewhere in between these
extremes. 

When we say an implementation delivers "lightweight isolates" that's a 
statement about how much new baggage must be arranged to support a new isolate 
vs how much metadata is simply reused.  So, for example, the U. of Utah 
prototype of a JSR-121 draft provides lightweight isolates and features lots 
of sharing of class and other contstant data. The reference implementation we 
tried to get into Tiger offered nothing at all. It could have gone further,
for example forking but not using an exec of the launcher, but that would have 
gotten tangled up with the class data sharing and created engineering 
dependencies that we couldn't afford.

You said to Curt:

>The advantage to couple Isolates with a shared memory area is about the 
>same as
>providing a messaging facility between them: You can move data from one
>Isolate to the other. A shared memory area seems like the most efficient 
>way to do
>this between Isolates and even between different VMs on the same host or 
>cluster.

But looks can be deceiving. :-) If you do a little research with the above
mapped buffers (or any similar scheme with real shared memory accessed by
distinct logical address ranges) you'll see it gets nasty very fast. But you say
you want a messaging system anyway? What to do? How about using the JSR-121
facility that was specifically designed to solve this problem and other very
fundamental problems with isolate communication? This is of course the Link
class. A lot of effort went into the Link specification (thanks especially
to SAP) to make sure it can benefit from advanced implementation techniques
that avoid the need for any worry about performance. But a more basic value of
Link is that it allows for reasoning about program correctness (some of us
think it might be possible to work Link into a pi calculus some day).

And the fundamental thing about Link, which is where I thought you were headed
when you brought up shared memory, is that it is designed to pass Java
objects. Ad hoc schemes with shared memory areas are stuck with primitive data 
and String or the need for more ad hoc code to apply serialization. 

And of course if you need more general communication there are a slew
of alternatives available with current Java via java.nio, RMI, etc.

Regards,
Pete