Research goal is transparent extension of Java programming model and facilities to a clustered environment. More for performance, than failure issues.
Design Approaches:
The executive summary is that there is some work going on to make Java cluster-aware at the VM level. I'm not sure why Jini wasn't mentioned more, since it seems like a natural fit for clusters. If I ever need to do some clustering, I can check in on the above projects to see if there is a fit.
Design Approaches:
- Cluster-aware JVMs (potentially optimal [close to hardware], but loses portability)
- Compile to cluster-enabled layer (ex. DSM; good performance, but lose portability and impedence mismatch)
- Systems using standard JVM (transforms at code or bytecode level). lose performance but get portability
- Hyperion - compiles to C code that is DSM aware
- Jackal - violates Java memory model
- Java/DSM (Rice, 1997) - piggybacks on existing DSM, no JIT
- cJVM (aka trusted JVM) (IBM, 1999) - proxy objects for non-local access (smart), no JIT
- Kaffemik (Trinity college, 2001) - based on kaffe VM, scalable coherent interface, JIT
- Jessica2 (2002) - JIT support, thread migration
- dJVM (2002) - based on Jikes
- JavaParty (1997) - pre-processor + runtime compiles to RMI. Requires langauage change
- JSDM (2001) - supports SPMD apps, not full Java technology
- JavaSplit - bytecode transformation, integrated custom DSM
- J/Orchestra - application partitioning, bytecode transformation
The executive summary is that there is some work going on to make Java cluster-aware at the VM level. I'm not sure why Jini wasn't mentioned more, since it seems like a natural fit for clusters. If I ever need to do some clustering, I can check in on the above projects to see if there is a fit.