[concurrency-interest] Shared Memory ?
Pete.Soper at Sun.COM
Wed Jun 8 14:12:17 EDT 2005
Ernst, Matthias wrote:
> 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
> * 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.
More information about the Concurrency-interest