Browse Prior Art Database

System and Method for Shared Memory/File System Java ObjectGroups in Clustered JVM

IP.com Disclosure Number: IPCOM000021597D
Original Publication Date: 2004-Jan-26
Included in the Prior Art Database: 2004-Jan-26
Document File: 3 page(s) / 45K

Publishing Venue

IBM

Abstract

In the area of grid computing and Java* software, this innovation describes a system and method for remotely and transparently accessing Java objects, and when the objects are hosted on machines with the sharing the same high-speed memory bus, then directly addressing them through shared memory.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

System and Method for Shared Memory/File System Java ObjectGroups in Clustered JVM

Disclosed is a system and method for remotely and transparently accessing Java* objects, and when the objects are hosted on machines with the sharing the same high-speed memory bus, then directly addressing them through shared memory.

The problem is that in grid computing environments with large numbers of remote objects, the performance of remote calls, particularly to access data fields of objects, is a concern. The Java JVM does not currently support an integrated shared memory capability which is important for grid computing.

For systems that provide a blades-like architecture, where many individual CPUs are combined into a rack, there is sometimes a very high speed back plane that allows the operating system to address shared memory.

By grouping Java objects into groups and placing groups that are frequently accessed remotely into the shared-memory, there is very high speed access to these objects. This is of particular advantage for grid computing where there may be many, many CPUs linked together into a common computing environment. This innovation allows this hardware capability to be leveraged by the clustered JVM.

The JVM would have a loadable module for access to objects within an Object group. A speciallized implementation of this interface would allow objects to be stored in shared memory. The RAM semaphores for controlling access to this shared memory would also hosted in the shared memory, allowing very high speed access by a large number of computers within a group.

This would have a significant reduction in the amount of actual remote traffic within a single Java Virtual Machine spanning multiple physical machines.

The interface to the loadable shared memory module would be like the interface to the Java Heap. In fact, the Java Heap itself could be provided as a loadable module conforming to the same interface. Therefore, new heap and memory technologies could be used to extend the capabilities of the Java JVM.

public interface ObjectGroup {

// get information about the nature of the Object group // local memory, remote memory, virtual memory ObjectGroupInfo getObjectGroupInfo();

// create a group of this type void createGroup(long ObjectGroupID, int size) throws

ObjectGroupTooBigException, ObjectGroupAlreadyExistsException;

1

Page 2 of 3

// destroy a group of this type void destroyGroup();

// how much free memory exists in this group long freeMemory();

// what is the total size of this group long totalMemory();

// create a new object in this group byte[] /...