[Isolate-interest] Re: [concurrency-interest] Shared Memory ?

[Pete Soper]

Ernst, Matthias wrote:
> Hi,
> 
> I'm musing about java-to-java/java-to-native, shared memory,
> inter-process communication. Is stuff like that on the list of things
> you see as a possible Java feature?
> 
> I imagine an API for
> * creating/deleting shared-memory descriptors
> * attaching to a shared-memory descriptor, yielding a DirectByteBuffer
> * an extension of j.u.c.atomic to support atomic instructions on such
> areas
> * basic IPC abstractions on top
> 
> I guess a small JNI library + sun.misc.Unsafe might already go a long
> way. Well, I just see there's no intrinsic like
> sun.misc.Unsafe.compareAndSwap*(long address, expectedValue, newValue)
> (the existing methods all take an object). Or is there?
> 
> What do you think? I'm thinking of some sort of crash-resilient, shared
> area for a set of VMs. Well, ideally that area would be a
> garbage-collected heap but let's stay realistic. Gemstone's been
> offering something like that for a while.
> 
> I see this might be complementary to the isolate effort.
> 

Multiple 1:1 style isolation prototypes (where each isolate is a JRE 
instance) exploited shared memory. One set made the entire aggregate 
state (all isolates having a common ancestor) in shared memory. Actually 
the design made provisions for almost any shareable object with basic 
lock semantics, such as a disk file. A vastly superior, feature complete 
implementation (albeit with heavy J2SE dependencies) that got close to 
inclusion in Tiger held the shared state to an absolute minimum (a pair 
of words, as I recall). The aim was robustness in the face of arbitrary 
failures of individual isolates. I have no idea what the plans are for 
the 121 RI (I had to move on to other things last December) but suspect 
shared memory and synchronization will be involved if the RI is 1:1 
style. Actually if it's not 1:1 it will still involve shared memory, but 
perhaps not the type you're writing about!

I personally think that hoisting (more) raw (bytes vs objects) shared 
memory manipulation up into a public Java API intended for applications 
would be at least as compromising to Java's safety guarantees as JSR'ing 
Unsafe and making it available to application classes (i.e. not 
requiring users to be on the bootclass path, which at least tends to 
involve debugged code). To be complementary to the spirit of isolates 
such APIs would have to be both OO and neutral with respect to 
implementation styles while doing no harm with respect to the safety of 
the runtime environment. I'm in no position to be a wet blanket about 
this: just my two cents as they say.

-Pete