MXPA00008635A - Arrangement for executing program code with reduced memory requirements - Google Patents

Abstract

A Java virtual machine (2), comprises an execution engine for executing Java byte code and a memory management system (14). The memory management system (14) performs garbage collection to remove objects that are not reachable from the current state of the Java program. In the prior art memory management system objects of the representing a class definition are only removed from memory if the classloader object which has loaded the class object is not reachable. According to the present invention the memory management system (14) is arranged for removing classes which do not have any instantiated objects which can be reached in the present state of the program even if the classloader is still reachable. This results in a substantial saving of memory. Preferably the objects representing a class definition have a method which can signal to it that the definition can be deleted from memory if it has no instantiated objects anymore.

Description

ARRANGEMENT FOR EXECUTING PROGRAM CODES WITH REDUCED MEMORY REQUIREMENTS FIELD OF THE INVENTION The present invention relates to an arrangement for executing program codes, the arrangement comprises the ^ definition of the loading means for loading at least two definition entities in the memory, definition entities are associated with the definition loading means, - the arrangement further comprises means for creating objects according to the definition entity. The present invention also relates to a method for executing program codes and a tangible means containing a computer program to perform a method for executing program codes.

BACKGROUND OF THE INVENTION An arrangement according to the preamble is known from the publication "The Specification of the JavaMR Virtual Machine" by Tim Lindholm and Frank Yellin, which is available from the Sun network site and became the printed book, September 1996, first impression. In recent years the popularity of the Java platform has increased substantially. Java is a platform which comprises the Java language which is compiled to a byte code which is executed in a Java Virtual Machine. The use of a byte code that is executed in a virtual machine has the advantage that the compiled byte code can be executed in any combination of physical components and operating system if there is a virtual machine for such a combination. The Java language is object oriented, which means that during the execution of the program objects are created according to a definition entity, which can be a class or an interface in the Java language. Before the objects can be created, the necessary definition entities (classes or interfaces) have to be loaded first into the memory. This load is made by the definition loading media, which are called class loaders in the Java language. Different means of definition loading may exist for different forms of load definition entities. In Java there may be, for example, different class loaders to load classes from a disk, from a TCP / IP-based network or load them from an MPEG-2 transport stream. The Java virtual machine has a memory management system which performs garbage collection to automatically suppress objects and classes that are not needed anymore.

When Java is going to be used in a consumer's home appliances such as TV and boxes placed at the top, only limited amounts of memory resources are available. Currently, the use of Java for home applications is very difficult due to the limited amount of available memory.

BRIEF DESCRIPTION OF THE INVENTION The object of the present invention is to provide an arrangement according to the preamble in which the amount of memory required is decreased. To achieve the objective, the arrangement according to the invention is characterized in that the array comprises memory management means for removing the memory definition entities that do not have related objects, the definition loading means are associated with defining entities that still have related objects. By removing the definition entities that do not have objects already related to the memory, substantial amounts of memory can be released, resulting in the arrangement requiring less memory than the arrangement according to the prior art. The invention is based on the recognition that the current specification of the Java virtual machine prescribes that a definition entity can only be suppressed if its definition load means are not already reachable. This means that there are no objects already of which the definition entity has been loaded by the definition loading means. This will be clarified in the following example. If a class loader (definition load media) has loaded two classes (definition entities), a loaded first class that has no related objects can no longer be removed from memory as long as the other class still has related objects. The result of this is that "the classes are still unnecessary in memory." Through the use of the idea of the invention according to the present invention, classes can be downloaded as soon as they are no longer needed. the present invention is characterized in that the array comprises designation means for designating defining entities as removable, since the memory management means are arranged to remove from the memory definition entities that do not have related objects when the definition entity is defined. designated as removable, and since memory management means are arranged to remove from memory the definition entities that correspond to definition loading means that are associated only with definition entities that do not have related objects.

There may be circumstances in which it is undesirable that definition entities that do not have related objects are always removed from memory. This may be the case when the class variables are modified by the execution of class methods. If such a class is removed from memory and recharged when necessary again, the value of the variable class can be changed. By removing only the definition entities without related objects when they are designated as removable, the application program can control this removal by designating a definition entity as removable or non-removable. A further method of the invention is characterized in that the array comprises storage means for storing an identification of the definition entities that are designated as removable. An easy way to communicate to memory management means if a class can be downloaded and if it does not have related objects is stored in a table in which all loaded classes are entered along with an indication of whether this class is removable or not. . Alternatively, it is possible to store the identification- in an object header associated with each class object.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will now be explained with reference to the drawings. Figure 1 shows an architecture of a Java virtual machine in which the present invention can be used. Figure 2 shows a class loader with related classes and instantiated objects. Figure 3 shows two class loaders, one that has a class with an intact object. Figure 4 shows a flow chart of a program according to the invention for use in the memory management system 14 according to Figure 1.

DETAILED DESCRIPTION OF THE INVENTION In the Java virtual machine according to Fig. 1, a subsystem of administration of classes ß is arranged to load classes not present in the memory of a local rigid unit or of a network. The classes to be loaded by the class management subsystem 6 are verified first by a code 4 verifier. Normally only the loaded classes of a network are verified because they can be from an unknown, less reliable source. When loading the classes, a syntax check is carried out. The "semantic" consistency of the loaded class is also verified. This includes, for example, the verification of whether the constants defined in a class are consistent with their type. For example, it is verified if the constants defined as ordered sequences or strings are actually ordered sequences or strings. During the execution time, a byte code check is carried out. This includes verifying the consistency of the stack, that is, verifying that an overflow and subflow of the stack does not occur. This also includes checking if the type of data entered in the variables corresponds to the declaration of such variables. An execution engine 8 is arranged to execute the verified byte code. For this execution the execution engine has three subsystems available, ie a subsystem to call the system 8 to invoke the operating system to perform certain tasks, such as loading an actual file of a disk or a network, or presenting elements in graphics on a visual representation device. In addition, the Virtual Machine comprises a link system 12 used to create separate links. The link subsystem 12 is also arranged to synchronize separate links. The Java VM also comprises a memory management subsystem 14 which includes a garbage subsystem to automatically remove obsolete elements from memory. In the Sun implementation of the Java VM, a garbage collection algorithm called "mark and sweep" is used. This type of garbage collection algorithm is known to those skilled in the art. In this algorithm, each object present in the stack has a so-called brand bit. The garbage collection process starts with the reset of the mark bit for all the objects present in the stack. Subsequently, all the fields and variables are examined with reference to the objects in the stack. For each object in the stack that is referenced by a field or variable, the mark bit is set. Finally, the garbage collector sweeps the stack and retrieves the memory area used by objects for which the mark bit was not set. Finally, the Java VM comprises a subsystem of Native Method Interface 16 that allows the use of functions written in C, C ++ or assembler. This may be convenient for reusing existing libraries or for using optimized assembler routines to improve performance. In the diagram according to Figure 2, "the objects present in the stack of the Java VM according to Figure 1 are presented. Figure 2 shows a first class 22 and a second class 20, which are loaded by a loader class 18. From class 22 an object 24 is instantiated and class 20 has no instantiated objects When the garbage collection algorithm according to the prior art is used, none of the objects 18, 20, 22 and 24 it will be garbage collected, because the class 18 loader is still reachable (it has an instantiated object of a class loaded by class 18 loader.) In the arrangement according to the invention, class 20 can be removed from memory because it has no instantiated objects.Preferably, a method is added to the class to indicate if a class can be downloaded when it does not already have instantiated objects.The syntax of such method can be "AllowDownloadClass (class) ". This method you can set a bit in the class header of the relevant class indicating that this class is suppressible. Alternatively, it is possible to build a table in the VM in which all classes are registered. In Figure 3 it is represented another group of objects present in the stack of a Java VM according to Figure 1. Figure 3 shows a first class 36 loader that has loaded a first class 32 and a second class 34 None of the classes 32 and 34 is reachable. Those classes 32 and 34 and their class 36 loader will be removed from memory regardless of whether the method of AllowDownloadClass has been called or not, because the class 36 loader is not reachable. Figure 3 also shows a second class 26 loader which has loaded a class 28 from which an object 30 is being urged. Class 28 has an achievable object 30. Consequently class 26 loader, class 28 and object 30 will not be downloaded (removed from memory). It is observed that in the Java 1.2 SDK the concept and reference objects were introduced, resulting in the objects being strong and weakly reachable. The garbage collector of the prior art removes all objects that are not strongly attainable. It is noted that, when using reference objects, the achievable concept as used in the above explanations with reference to Figures 2 and 3 means strongly alcañzable. In the following graph according to Figure 4, the numbered instructions have the following meanings. No. Registration Meaning 40 START Start the garbage collector. 42 FINDING OBJECT The reachable object was found. REACHABLE 44 MARKING OBJECT The object is marked as attainable REACHABLE. 46 DO ALL OF THEMSELVES checked if all objects OBJECTS? they have been examined. 48 REMOVE OBJECT The new object for garbage collection was removed. 49 IS THE OBJECT Is it checked if the MARKING was marked? object. 50 IS THE OBJECT ONE It is verified if the object is a CLASS ?, class. 52 IS THE OBJECT Is it verified if the object is SUPRIMABLE? suppressible 54 FIND CHARGER The CLASS class loader corresponding to the current object is located. 56 IS THE CHARGER Checked if the charger of CLASS MARCHED class was marked. 58 DELETE OBJECT. The object is deleted from memory. 60 MAKE ALL 'Is it checked if all objects OBJECTS? they are processed. 62 END Ends the garbage collector execution.

In instruction 40 of the program according to Figure 4, the program starts and the necessary initializations take place. In instruction 42, starting from the fields and variables that correspond to the current program status, the achievable objects are searched. If an attainable object is found, the object is marked in instruction 44. Instruction 46 is checked if all reachable objects were found. This is the case when all the fields and variables in the current state of the VM have been plotted for the corresponding objects. If all the reachable objects are not found, the program jumps to instruction 42 to find the next reachable object. If all possible achievable objects are found, the "mark phase" of the "mark and sweep" garbage collection algorithm is completed, and the "sweep phase" begins. In instruction 48 an object is selected for the examination. Instruction 49 is checked if the object is marked. If the object is marked, it must not be deleted from memory, and the program continues in instruction 60. If the object is not marked, in instruction 50 it is checked if the object is a class. This can, by. example, determined from a field in an object header associated with the object. If the object is not a class, the program continues with instruction 58 in which the object is deleted from memory. Subsequently the program continues in instruction 60.

If the object is a class, instruction 52 checks whether the class is designated as deletable. This can be done, for example, by checking whether a "deleteable bit" has been placed in the header of the object that invokes the AllowDownloadClass method. Alternatively, it is also possible that a table containing all the suppressible classes is consulted. If the object is suppressible, in instruction 58 the object of the class is deleted in instruction 58. If the class is not marked as suppressible, in instruction 54, the class loader that loaded the class is reached. This can be done by reading a table in the VM, which includes the loaded classes and their associated class loader. After having found the class loader, instruction 56 is verified if the class loader object is checked. If he. Class loader is not marked, instruction 58, the object of the class is deleted. If the class loader is marked, the class is not deleted from memory and the program continues in instruction 60. In instruction 60 it is checked if all the objects in the stack have been processed. If this is the case, the program ends in instruction 62. Otherwise the program continues with instruction 48 to process the next object in the stack.

Claims (9)

CHAPTER CLAIMING Having described the invention, it is considered as a novelty and, therefore, what is claimed is contained in the following CLAIMS:

1. An arrangement for executing pro codes, the array comprises definition loading means for loading at least two definition entities into the memory, the definition entities are associated with the definition loading means, the array further comprises means for creating objects for creating objects according to the defining entity, characterized in that the array comprises memory management means for removing from memory the definition entities that do not have objects related to the definition loading means being associated with definition entities that they still have related objects

2. The array according to claim 1, characterized in that the array comprises designation means for designating defining entities as removable, and because the memory management means are arranged to remove from the memory entities of the memory. definition that they do not have related objects when the definition entity is designated as removable, and because the management means are arranged to move definition entities from the memory that correspond to definition loading means that are associated only with the definition entities that do not have related objects.

3. The arrangement in accordance with the claim 2, characterized in that the array comprises storage means for storing an identification of the definition entities that are designated as removable.

4. A method for executing pro codes, the method comprises loading at least two definition entities in memory by means of a definition load entity, the definition entity is associated with the definition load entity, the The method further comprises creating objects according to the definition entity, characterized in that the method comprises removing from the memory definition entities that do not have related objects, the definition load entity is associated with definition entities that still have related objects. .

5. The method according to claim 4, characterized in that the method comprises the designation of defining entities as removable, removing from the memory definition entities that do not have related objects when the definition entity is designated as removable, and because the method involves removing from memory memory definition entities associated only with definition entities that do not have related objects.

6. The method according to claim 5, characterized in that the method comprises storing an identification of. the definition entities that are designated as removable.

7. A tangible means containing a computer pro for performing a method for executing pro codes, the method comprises charging at least two definition entities to memory by means of a definition load entity, the. definition entity is associated with the definition-loading entity, the method further comprises creating objects according to the definition entity, characterized in that the method comprises removing from memory, definition entities that do not have related objects, the. definition load media are associated with definition entities that still have related objects.

8. The tangible medium according to claim 7, characterized in that the method comprises designating defining entities as removable, removing from the memory definition entities that do not have related objects when the definition entity is designated as removable, and because the The method includes removing from memory memory definition entities associated only with definition entities that do not have related objects.

9. The tangible medium according to claim 8, characterized in that the method comprises storing an identification of definition entities that are designated as removable.