Class loading model

Details Class loading model Class loading model

1999-04-16

2002-01-15

Dam, Tuan Q. (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S152000, C707S793000, C709S203000

Reexamination Certificate

active

06339841

ABSTRACT:

FIELD OF INVENTION
This invention relates to a class loading model for an object orientated programming language.
BACKGROUND
The size and price of memory chips has decreased steadily since the advent of computers and as a consequence the storage capacity on a machine has increased considerably over time. Ten years ago 64 k bytes of RAM was the norm, now it is 64 M bytes and in the next ten years it will possibly be 64 G bytes. This increase in RAM memory storage on a computer has been followed if not lead by an increase on the demands on storage by larger memory intensive software applications. One solution introduced by some operating systems to reduce the RAM memory required is to use dynamic linking of class libraries, that is to only load libraries of classes when they are needed by an application. This allows the available RAM to be used more efficiently. One problem with loading whole sets of classes is that more classes are loaded than are actually used and time is wasted loading the unused classes.
Dynamic loading of individual classes is part of a Java enabled environment whereby a small application or applet is dynamically sent from server to client on request. The applet comprises a number of Java classes needed for the execution of the applet and a set of classes may be loaded in a container called a Jar or an individual class may be loaded. In this way the Java environment saves memory by only loading the classes it needs to run the application or applet. Time is also saved as only the classes that are needed are loaded. However, speed of operation of the Java environment is critical and a major drawback of using the Java language.
SUMMARY OF THE INVENTION
According to one aspect of the invention there is provided a method of processing a class file on a computer system comprising: identifying independent parts within the class; creating separate components for each separable part of the class; and storing the components so that each component of the class is individually identifiable and accessible.
In this way the granularity of loading is increased within the classes with only the components needed within the class being loaded and used. This leads to an increased speed of operation and a reduction in the memory needed.
The separable parts of the class identified are the class meta data part and the methods part. Although the ClassFile is a serialised sequence of byte code, the meta data part and method byte code parts are contiguous and not combined allowing separation and extraction from the ClassFile.
In the case where a method requires other methods in the class for its operation, the metadata component contains information indicating which methods are dependent and should be loaded together. This allows the method loader to be more efficient in the loading of the individual methods whereas, if each method was loaded only when referenced, the speed of operation of the system would be reduced.
According to another aspect of the invention there is provided a method implementing an object oriented program language on a computer comprising: identifying a class which is not within the program domain; and introducing to the program domain only the minimum components of the class which are necessary for commencing processing of the class. The program domain is the environment in which the program runs and in this embodiment it is a Java Virtual Machine “JVM”. The object oriented language is the Java programming language which is loaded into the JVM as classes and is processed by interpreting the bytes codes.
Advantageously the method further comprises identifying a separable meta data component and separable method components of the class and introducing the meta data component and only the minimum number of method components to the program domain. The meta data component may itself be separated into further components to further increase the level of granularity.
Furthermore, the method further comprising setting a field in the program domain to indicate that method byte code for that method has not been downloaded to the client. This field points at a mechanism for loading the component of method byte code.
Classes are packaged into ClassFiles for distribution and contain components of execution code called methods that may or may not be used during the execution of a program. Due to the over supply of methods such classes are bulky in terms of byte code; this is a major factor in the transfer time from the server to the client. Due to the number of applet transfers that take place over the Internet at present and the expanding number of Java applications envisaged in the future it would be desirable to reduce the transfer time for Java applications and applets.
Use of skeletal Java classes is known in the design of remote applications. However this skeletal class contains only basic metadata including visual information and other data needed for designing an applet. No method data is included in this skeletal class as the skeletal class is not intended to be executed.
The class metadata comprises a class description component, a method table and a constant pool.
Despite Java's compact representation, the classes distributed are often numerous and large. Much of the bulk of a class is made up of the methods themselves. Often, many of the methods downloaded are never used on any given occasion. This invention proposes the distribution of class data at a method level of granularity. This results in the following scenario:
1) A client program requires the use of a remote class
2) A skeleton definition of the class is sent to the client. State metadata and constant pool information is downloaded at this point together with any method identified as always needing to be downloaded.
3) When a method is actually referenced, lazy verification also triggers the downloading of that fragment of the class file. Only those methods actually referenced are transferred.
As a result of this invention the following is achieved: reduced network stress as a result of the reduced data flows; reduced base memory requirements of the Java application; improved client performance as a result of the above; and improved client performance as a result of a more incremental download.
The Java class loader is modified so that only the minimum amount of class metadata is downloaded initially. The existing method reference opcode are modified so that the method code is downloaded at the time of first reference. Once the method is downloaded, the opcode is replaced with its ‘quick’ counterpart. If the method was previously downloaded by another reference, subsequent references are resolved using the existing mechanisms.
The application proposes that the classes should be loaded without their methods. The methods represent most of the bulk of the class and are often never referenced.
The lazy verification is extended to cause the downloading of individual methods as they are referenced.
Components of the class which are no longer used by the application may be discarded to free up the memory space, this is similar to garbage collection of unused classes but on a finer granular scale. One extreme way to discard unused components would be to discard all the methods not active on the Java stack, if the individual components were needed later they could be reloaded with ease.


REFERENCES:
patent: 5303380 (1994-04-01), Tenny et al.
patent: 5619710 (1997-04-01), Travis, Jr. et al.
patent: 5815718 (1998-09-01), Tock
patent: 5966542 (1999-10-01), Tock
patent: 5966702 (1999-10-01), Fresko et al.
patent: 5974428 (1999-10-01), Gerard et al.
patent: 6016392 (2000-01-01), Jordan
patent: 6026237 (2000-02-01), Berry et al.
patent: 6061520 (2000-05-01), Yellin et al.
patent: 6085198 (2000-07-01), Skinner et al.
patent: 6092120 (2000-07-01), Swaminathan et al.
patent: 0777177 (1997-06-01), None
IBM Technical Disclosure Bulletin, “Java Dynamic Class Loader,” vol. 39, Issue No. 11, pp. 107-108, Nov. 1, 1996.*
Jensen et al., “Security and Dynamic Class Loading in Java: A formalisation,” IEEE Proceedings of 19

Affiliated with

Also associated with

Rating

Class loading model does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Class loading model, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Class loading model will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2873822