IBM Israel
Skip to main content
 
Search IBM Research
   Home  |  Products & services  |  Support & downloads  |  My account
Select a Country Select a country
IBM Research Home IBM Research Home
IBM Haifa Labs Homepage IBM Haifa Labs Home

Cluster Virtual Machine for Java

Distributed Computing Systems
Project Homepage
 ·Overview
 ·Motivation
 ·Application Model
 ·Approach
 ·Benchmark Results
 ·Optimizations
 ·Status
 ·Related Works
 ·Papers
 ·Contact Information
Feedback


Application Model
  Application Model: Java Server Applications

We aim to provide a solution to scale a particular class of Java applications called Java Server Applications (JSAs). These are second tier applications with the basic structure of a concurrent daemon that:
  • Accepts a sequence of requests from clients.
  • Typically accesses an external "database" in processing the request.
  • Has some interactions (i.e., sharing) between requests.

In general terms, scalability for a Java Server Application means increasing the number of client requests it can satisfy. Because we are interested in applications that are concurrent daemons, we assume that the applications have been explicitly written to use Java threads. (See the Threading Model for a discussion of this assumption.) We explicitly try not to parallelize the existing serial code.

The last characteristic, interactions between requests, is an essential feature that we would like to support.

The figure below is a schematic presentation of the Java Server Architecture with the Java Server Application in the middle running on top of a cluster JVM. We see that the cluster JVM is distributed over the nodes of the cluster and provides multiple first tier clients access to the Java Server Application, which in turn accesses data from various third tier "databases".

Java Server Application Structure

The goal of Cluster VM for Java is to give the application the view of a traditional single node JVM. This means that as far as application programmers are concerned, they only see:
  • Traditional Java memory and object models
  • Traditional Java threads

  Models Requirements on Cluster VM for Java

The goal of Cluster VM for Java, in general terms, is to be able to take an arbitrary Java server application and allow the capacity of the application to be scaled upwards by "throwing more hardware at the problem." This means meeting the following application requirements:
  • High Capacity
    • Number of user bytecodes per unit time
  • High Throughput
    • Number of requests per unit time
  • Fairness
    • Between independent requests
  • Long Running
    • Resilience to faults
  • Security
    • No less than a traditional JVM
  • Transparency
    • Execute arbitrary Java (server) code. In other words, no coding changes should be required to execute an arbitrary JSA on Cluster VM for Java
  • Sharing
    • Over space and time
      • Space: Concurrent requests from multiple clients
      • Time: Sequential requests from the same or different clients
      • Persistent and transient data
      • DB: Used to share persistent data
      • Java Objects: Used to share transient data and data cached from DB

  Assumptions About Java Server Applications

We make several assumptions in our model regarding the Java Server Application. First, we are only interested in supporting applications that are well written Java applications. This means that the applications are "Pure" Java, that only native code is via JNI, and that there is no OS-specific code. Second, at this point in time we are interested in supporting a single application in our JVM. As a related point, we assume that the application handles any necessary inter-request security.

Third, we assume that the third tier is not the bottleneck. If the third tier were the bottleneck, there would be no point in trying to scale up the second tier. Realistically, given the state of Java and the effort that has been historically invested in increasing the scalability of the third tier, we believe this is a reasonable assumption.

We also make several other assumptions about the application that can be thought of as tactical assumptions for the sake of simplifying our research.

  • Application code is correct
  • Application is well behaved with respect to synchronization
    • Synchronization is only via Java monitors
      • There is no synchronization via OS resources even if encapsulated in Java objects
      • There is no synchronization via priorities

We believe these assumptions eliminate a very small fraction of applications.

  Threading Model

We are interested in applications that were programmed as concurrent daemons. In practical terms, we assume that the programmer has made explicit use of threads, associating a thread with each client request. More precisely, we consider the model where the server listens on a socket for a new client request. When the request arrives, the server hands the request to a thread for processing, where the thread may either be newly created or retrieved from a pool of threads. An application with this structure is inherently parallel (even if it executes on a uni-processor) and the programmer must have addressed the issue of synchronization to shared resources. We want to take advantage of the parallelism in the application to provide true parallelism by distributing the execution of the threads over the nodes of a cluster.

  Sharing

As we stated previously, sharing is a significant characteristic of the application model. We aim to support applications with "some degree" of sharing. Informally, we can consider a spectrum on the degree of sharing that exists between requests, where the spectrum runs from zero to one, where zero is no sharing. If there is no sharing, the requests are totally independent; if the level of sharing is at one, only a single object is used by all requests.

In addition to looking at the degree of sharing, we can also consider what is shared. We distinguish between sharing that occurs implicitly due to the behavior of the JVM (e.g., bytecodes, class objects, strings, etc.) and sharing that occurs due to explicit programmer actions (e.g., shared objects and static data members). The implicit sharing is in some sense accidental and not essential except to the degree it enables the second type of sharing (e.g., shared class objects enable shared static data members). We are interested in the degree of explicit sharing.

We intentionally do not define how much and what type of sharing we will support; although for our research, zero is not an interesting point on the spectrum of sharing. Part of this research is to understand how much and what type of sharing between requests we can support on a cluster, while still achieving the goals of high capacity and high throughput.



































 

  About IBM  |  Privacy  |  Legal  |  Contact