WO2000041079A2 - Arrangement for executing program code with reduced memory requirements - Google Patents
Arrangement for executing program code with reduced memory requirements Download PDFInfo
- Publication number
- WO2000041079A2 WO2000041079A2 PCT/EP1999/010301 EP9910301W WO0041079A2 WO 2000041079 A2 WO2000041079 A2 WO 2000041079A2 EP 9910301 W EP9910301 W EP 9910301W WO 0041079 A2 WO0041079 A2 WO 0041079A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- definition
- memory
- entities
- compπses
- objects
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44594—Unloading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5022—Mechanisms to release resources
Definitions
- the present invention relates to an arrangement for executing program code, said arrangement comp ⁇ ses definition loading means for loading at least two definition entities into memory, said definition entities being associated with said definition loading means, the arrangement further comp ⁇ ses object creating means for creating objects according to said definition entity
- the present invention is also related to a method for executing program code and a tangible medium carrying a computer program for performing a method for executing program code.
- Java is a platform which comp ⁇ ses the Java language which is compiled to a byte code which runs on a Java Virtual Machine.
- the use of a byte code which runs on a virtual machine has the advantage that the compiled byte code can be executed on every combination of hardware and operating system if a virtual machine exist for such combination
- the Java language is object o ⁇ ented, which means that du ⁇ ng the execution of the programs objects are created according to a definition entity, which can be a class or an interface in the Java language. Before objects can be created, the needed definition entities (classes or interfaces) have to be loaded first in memory. This loading is done by the definition loading means, which are called class loaders in the Java language. There can exist different definition loading means for different ways of loading definition entities. In Java there can e.g. be different class loaders for loading classes from disk, from a TCP/IP based network or loading them from an MPEG-2 Transport stream
- the Java virtual machine has a memory management system which performs garbage collection to delete automatically objects and classes that are not needed anymore.
- garbage collection When Java is to be used in consumer appliances such as TV's and set-top boxes, only limited amounts of memory resources are available. Currently the use of Java for consumer applications is quite difficult due to that limited amount of memory available
- the object of the present invention is to provide an arrangement according to the preamble in which the required amount of memory is decreased.
- the arrangement according to the invention is characte ⁇ zed in that the arrangement comp ⁇ ses memory management means for removing from memory definition entities having no related objects, said definition loading means being associated with definition entities still having related objects.
- the invention is based on the recognition that in the present specification of the Java virtual machine it is presc ⁇ bed that a definition entity may only be deleted if its definition loading means is not reachable anymore. This means that no objects exist anymore of which the definition entity has been loaded by said definition loading means.
- classes may be unloaded as soon they are not needed anymore.
- An embodiment of the present invention is characte ⁇ zed in that the arrangement comp ⁇ ses designation means for designating definition entities as removable, in that the memory management means are arranged for removing from memory definition entities having no related objects when the definition entity is designated as removable, and in that the memory management means are arranged for removing from memory definition entities corresponding to definition loading means being associated with only definition entities having no related objects.
- class va ⁇ ables are modified by the execution of class methods. If such a class is removed from memory and is reloaded when it is needed again, the value of the class va ⁇ able may be changed
- the application program can control this removal by designating a definition entity as removable or not removable.
- a further embodiment of the invention is characte ⁇ zed in that said arrangement comp ⁇ ses sto ⁇ ng means for sto ⁇ ng an identification of definition entities that are designated as removable.
- An easy way of communicating to the memory management means whether a class can be unloaded if it has no related objects is to store a table in which all loaded classed are entered together with an indication whether this class is removable or not. Alternatively, it is possible to store the identification in an object header associated with each class object.
- Fig. 1 shows the architecture of a Java virtual machine in which the present invention can be used.
- Fig. 2 shows a class loader with related classes and instantiated objects.
- Fig. 3 shows two class loaders, one having a class with an instantiated object.
- Fig. 4 shows a flow diagram of a program according to the invention for use in the memorv management svstem 14 according to Fig. 1.
- a class management subsystem 6 is arranged for loading classes not present in memory from a local hard d ⁇ ve or from a network
- the classes to be loaded by the class management subsystem 6 are first checked by a code ve ⁇ fier 4 Normally only the classes loaded from a network are ve ⁇ fied because they can be from an unknown, less reliable source At loading the classes a syntax check is performed Also the "semantic" consistency of the loaded class is checked This includes e.g. the checking whether the constants defined in a class are consistent with their type. It is e.g checked whether constants defined as st ⁇ ngs are indeed st ⁇ ngs
- Du ⁇ ng runtime a byte code ve ⁇ fication is performed. This includes checking of consistency of the stack, i.e. ve ⁇ fying that no stack overflow and underflow occurs. It also includes checking whether the type of data put into va ⁇ ables corresponds to the declaration of said va ⁇ ables.
- An execution engine 8 is arranged for executing the ve ⁇ fied byte code.
- the execution engine has three subsystems available, i.e. a system call subsystem 8 for invobng the operating system to perform certain tasks, such as the loading of an actual file from disk or from a network, or displaying graphical elements on a display device
- the Virtual Machine comp ⁇ ses a thread system 12 used for creating separate threads.
- the thread sub system 12 is also arranged for synchronizing separate threads.
- the Java VM also comp ⁇ ses a memory management subsystem 14 which includes a garbage collector for automatically removing obsolete items from memory.
- a so-called "mark and sweep" garbage collection algo ⁇ thm is used. This type of garbage collection algo ⁇ thm is well known to those skilled in the art.
- each object present in the heap has a so-called mark bit.
- the process of garbage collection starts with resetting the mark bit for all objects present in the heap. Subsequently all fields and va ⁇ ables are examined for references to objects in the heap. For each object in the heap that is referenced by a field or va ⁇ able, the mark bit is set. Finally the garbage collector sweeps the heap and reclaims the memory area used by objects of which the mark bit is not set
- Java VM comp ⁇ ses a Native Method Interface subsystem 16, enabling the use of functions w ⁇ tten in C, C++ or assembler This may be convenient in order to reuse existing bra ⁇ es or to be able to use optimized assembler routines to improve performance
- FIG. 2 shows a first class 22 and a second class 20, which are loaded by a class loader 18 From class 22 one object 24 is instantiated and class 20 has no instantiated objects
- the class 20 can be removed from memory because it has no instantiated objects.
- a method is added to the class Class to indicate whether a class can be unloaded when it has no instantiated objects anymore.
- Fig. 3 shows a first classloader 36 that has loaded a first class 32 and a second class 34. None of the classes 32 and 34 is reachable. These classes 32 and 34 and their classloader 36 will be removed from memory irrespective whether the method EnableClassUnloading is called or not, because the class loader 36 is not reachable.
- Fig. 3 shows also a second classloader 26 which has loaded a class 28 from which an object 30 is instantiated.
- the class 28 has one reachable object 30. Consequently the classloader 26. the class 28 and the object 30 will not be unloaded (removed from memory).
- the "mark phase” of the "mark and sweep” garbage collection algo ⁇ thm is completed, and the "sweep phase” is started.
- instruction 48 an object from the heap is selected for examination.
- instruction 49 it is checked whether the object is marked. If the object is marked, it must not be deleted from memory, and the program continues at instruction 60. If the object is not marked, in instruction 50 it is checked whether the object is a class. This can e.g. be 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 is continued at instruction 60
- the object is a class
- the class loader which loaded the class is searched. This can be done by reading a table in the VM which comp ⁇ ses the loaded classes and their associated class loader. After having found the class loader, it is checked in instruction 56 whether the class loader object is marked. If the class loader is not marked, in instruction 58 the class object is deleted. If the class loader is marked, the class is not deleted from memory and the program is continued at instruction 60.
- instruction 60 it is checked whether all objects in the heap have been processed. If this is the case, the program is terminated in instruction 62. Otherwise the program continues with instruction 48 to process the next object in the heap
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
- Debugging And Monitoring (AREA)
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 code with reduced memory requirements.
The present invention relates to an arrangement for executing program code, said arrangement compπses definition loading means for loading at least two definition entities into memory, said definition entities being associated with said definition loading means, the arrangement further compπses object creating means for creating objects according to said definition entity
The present invention is also related to a method for executing program code and a tangible medium carrying a computer program for performing a method for executing program code.
An arrangement according to the preamble is known from the publication "The Java™
Virtual Machine Specification" by Tim Lindholm and Frank Yelhn, which is available from the Sun web site and is converted from the pπnted book, September 1996, first pπnting.
In recent years the populaπty of the Java platform has increased substantially. Java is a platform which compπses the Java language which is compiled to a byte code which runs on a Java Virtual Machine.
The use of a byte code which runs on a virtual machine has the advantage that the compiled byte code can be executed on every combination of hardware and operating system if a virtual machine exist for such combination The Java language is object oπented, which means that duπng the execution of the programs objects are created according to a definition entity, which can be a class or an interface in the Java language. Before objects can be created, the needed definition entities (classes or interfaces) have to be loaded first in memory. This loading is done by the definition loading means, which are called class loaders in the Java language. There can exist different definition loading means for different ways of loading definition entities. In Java there can e.g. be different class loaders for loading classes from disk, from a TCP/IP based network or loading them from an MPEG-2 Transport stream
The Java virtual machine has a memory management system which performs garbage collection to delete automatically objects and classes that are not needed anymore.
When Java is to be used in consumer appliances such as TV's and set-top boxes, only limited amounts of memory resources are available. Currently the use of Java for consumer applications is quite difficult due to that limited amount of memory available
The object of the present invention is to provide an arrangement according to the preamble in which the required amount of memory is decreased.
To achieve said objective, the arrangement according to the invention is characteπzed in that the arrangement compπses memory management means for removing from memory definition entities having no related objects, said definition loading means being associated with definition entities still having related objects.
By removing definition entities having no related objects anymore from memory, substantial amounts of memory can be freed, resulting in that the arrangement requires less memory than the arrangement according to the pπor art. The invention is based on the recognition that in the present specification of the Java virtual machine it is prescπbed that a definition entity may only be deleted if its definition loading means is not reachable anymore. This means that no objects exist anymore of which the definition entity has been loaded by said definition loading means.
This will be made clearer in the following example. If a class loader (definition loading means) has loaded two classes (definition entities), a first loaded class having no related object anymore may not be removed from memory as long the other class still has related objects. The result of this is that classes remain unnecessary long in memory.
By using the inventive idea according to the present invention, classes may be unloaded as soon they are not needed anymore. An embodiment of the present invention is characteπzed in that the arrangement compπses designation means for designating definition entities as removable, in that the memory management means are arranged for removing from memory definition entities having no related objects when the definition entity is designated as removable, and in that the memory management means are arranged for removing from memory definition entities corresponding to definition loading means being associated with only definition entities having no related objects.
There may be circumstances that it is undesirable that definition entities having no related objects are always removed from memory This can be the case when class vaπables
are modified by the execution of class methods. If such a class is removed from memory and is reloaded when it is needed again, the value of the class vaπable may be changed
By only removing 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 not removable.
A further embodiment of the invention is characteπzed in that said arrangement compπses stoπng means for stoπng an identification of definition entities that are designated as removable.
An easy way of communicating to the memory management means whether a class can be unloaded if it has no related objects is to store a table in which all loaded classed are entered together with an indication whether this class is removable or not. Alternatively, it is possible to store the identification in an object header associated with each class object.
The present invention will now be explained with reference to the drawings.
Fig. 1 shows the architecture of a Java virtual machine in which the present invention can be used.
Fig. 2 shows a class loader with related classes and instantiated objects. Fig. 3 shows two class loaders, one having a class with an instantiated object. Fig. 4 shows a flow diagram of a program according to the invention for use in the memorv management svstem 14 according to Fig. 1.
In the Java virtual machine according to Fig. 1, a class management subsystem 6 is arranged for loading classes not present in memory from a local hard dπve or from a network
The classes to be loaded by the class management subsystem 6 are first checked by a code veπfier 4 Normally only the classes loaded from a network are veπfied because they can be from an unknown, less reliable source At loading the classes a syntax check is performed Also the "semantic" consistency of the loaded class is checked This includes e.g. the checking whether the constants defined in a class are consistent with their type. It is e.g checked whether constants defined as stπngs are indeed stπngs
Duπng runtime a byte code veπfication is performed. This includes checking of consistency of the stack, i.e. veπfying that no stack overflow and underflow occurs. It also
includes checking whether the type of data put into vaπables corresponds to the declaration of said vaπables.
An execution engine 8 is arranged for executing the veπfied byte code. For this execution the execution engine has three subsystems available, i.e. a system call subsystem 8 for invobng the operating system to perform certain tasks, such as the loading of an actual file from disk or from a network, or displaying graphical elements on a display device Furthermore the Virtual Machine compπses a thread system 12 used for creating separate threads. The thread sub system 12 is also arranged for synchronizing separate threads.
The Java VM also compπses a memory management subsystem 14 which includes a garbage collector for automatically removing obsolete items from memory. In the Sun implementation of the Java VM a so-called "mark and sweep" garbage collection algoπthm is used. This type of garbage collection algoπthm is well known to those skilled in the art. In this algoπthm. each object present in the heap has a so-called mark bit. The process of garbage collection starts with resetting the mark bit for all objects present in the heap. Subsequently all fields and vaπables are examined for references to objects in the heap. For each object in the heap that is referenced by a field or vaπable, the mark bit is set. Finally the garbage collector sweeps the heap and reclaims the memory area used by objects of which the mark bit is not set
Finally, the Java VM compπses a Native Method Interface subsystem 16, enabling the use of functions wπtten in C, C++ or assembler This may be convenient in order to reuse existing braπes or to be able to use optimized assembler routines to improve performance
In the diagram according to Fig. 2, objects present in the heap of the Java VM according to Fig 1 are presented. Fig. 2 shows a first class 22 and a second class 20, which are loaded by a class loader 18 From class 22 one object 24 is instantiated and class 20 has no instantiated objects
When using the garbage collection algoπthm according to the pπor art, none of the objects 18, 20. 22 and 24 will be garbage collected, because the classloader 18 is still reachable (having an object 24 instantiated from a class loaded by said classloader 18). In the aπangement according to the invention, the class 20 can be removed from memory because it has no instantiated objects. Preferably, a method is added to the class Class to indicate whether a class can be unloaded when it has no instantiated objects anymore. The syntax of such a method can be "EnableClassUnloading ( class )" This method can set a bit in the classheader of the relevant class indicating that this class is deletable Alternatively it is possible that a table is constructed in the VM in which all deletable classes are registered.
In Fig. 3 another group of objects present in the heap of a Java VM according to Fig. 1 is represented. Fig. 3 shows a first classloader 36 that has loaded a first class 32 and a second class 34. None of the classes 32 and 34 is reachable. These classes 32 and 34 and their classloader 36 will be removed from memory irrespective whether the method EnableClassUnloading is called or not, because the class loader 36 is not reachable.
Fig. 3 shows also a second classloader 26 which has loaded a class 28 from which an object 30 is instantiated. The class 28 has one reachable object 30. Consequently the classloader 26. the class 28 and the object 30 will not be unloaded (removed from memory).
It is observed that in the Java 1.2 SDK the concept of reference objects was introduced, resulting in objects that can be strongly and weakly reachable. The pπor art garbage collector removes all objects that are not strongly reachable. It is observed that, when reference objects are used, the concept reachable as used in the above explanations with reference to Figures 2 and 3 means strongly reachable.
In the flowgraph according to Fig. 4, the numbered instructions have the following meaning:
No. Inscπption Meaning
40 BEGIN The execution of the garbage collector is started.
42 FIND REACHABLE OBJECT A reachable object is found.
44 MARK REACHABLE OBJECT The object is marked as reachable.
46 ALL OBJECTS DONE ? It is checked whether all objects have been examined.
48 TAKE OBJECT A new object is taken for garbage collection.
49 IS OBJECT MARKED ? It is checked whether the object was marked.
50 IS OBJECT A CLASS ? It is checked whether the object is a class. 52 IS OBJECT DELETABLE ? It is checked whether the object is deletable. 54 FIND CLASS LOADER The class loader corresponding to the current object is located. 56 IS CLASS LOADER MARKED ? It is checked whether the class loader was marked. 58 DELETE OBJECT The object is deleted from memory.
60 ALL OBJECTS DONE ? It is checked whether all objects are processed.
62 END The execution of the garbage collector is terminated.
In instruction 40 of the program according to Fig. 4 the program is started and the necessary initializations take place. In instruction 42, starting from the fields and vaπables corresponding to the current state of the program, reachable objects are searched. If a reachable object is found, the object is marked in instruction 44. In instruction 46 it is checked whether all reachable objects are found. This is the case when all fields and vaπables in the current state of the VM have been traced for corresponding objects. If not all reachable objects are found yet the program jumps to instruction 42 for finding the next reachable object.
If all possible reachable objects are found, the "mark phase" of the "mark and sweep" garbage collection algoπthm is completed, and the "sweep phase" is started. In instruction 48 an object from the heap is selected for examination. In instruction 49 it is checked whether the object is marked. If the object is marked, it must not be deleted from memory, and the program continues at instruction 60. If the object is not marked, in instruction 50 it is checked whether the object is a class. This can e.g. be 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 is continued at instruction 60
If the object is a class, in instruction 52 it is checked whether the class is designated as deletable. This can e.g. be done by checking whether a "deletable bit" in the object header has been set by invoking the EnableClassUnloading method. Alternatively, it is also possible that a table containing all deletable classes is consulted. If the object is deletable, in instruction 58 the class object is deleted in instruction 58.
If the class is not marked as deletable, in instruction 54 the class loader which loaded the class is searched. This can be done by reading a table in the VM which compπses the loaded classes and their associated class loader. After having found the class loader, it is checked in instruction 56 whether the class loader object is marked. If the class loader is not marked, in instruction 58 the class object is deleted. If the class loader is marked, the class is not deleted from memory and the program is continued at instruction 60.
In instruction 60 it is checked whether all objects in the heap have been processed. If this is the case, the program is terminated in instruction 62. Otherwise the program continues with instruction 48 to process the next object in the heap
Claims
CLAIMS:
1 Arrangement for executing program code, said arrangement compπses definition loading means for loading at least two definition entities into memory, said definition entities being associated with said definition loading means, the arrangement further compπses object creating means for creating objects according to said definition entity, characteπzed in that the arrangement compπses memory management means for removing from memory definition entities having no related objects, said definition loading means being associated with definition entities still having related objects
2. Arrangement according to claim 1, characteπzed in that the arrangement compπses designation means for designating definition entities as removable, in that the memory management means are arranged for removing from memory definition entities having no related objects when the definition entity is designated as removable, and in that the memory management means are arranged for removing from memory definition entities corresponding to definition loading means being associated with only definition entities having no related objects.
3. Arrangement according to claim 2, characteπzed in that said arrangement compπses stoπng means for stoπng an identification of definition entities that are designated as removable.
4. Method for executing program code, said method compπses loading at least two definition entities into memory by a definition loading entity, said definition entity being associated to the definition loading entity, the method further compπses creating objects according to said definition entity, characteπzed in that the method compπses removing from memory definition entities having no related objects, said definition loading entity being associated with definition entities still having related objects
5. Method according to claim 4, characteπzed in that the method compπses designation of definition entities as removable, removing from memory definition entities having no related objects when the definition entity is designated as removable, and in that the method compπses removing from memory definition entities associated with only definition entities having no related objects.
6. Method according to claim 5, characteπzed in that said method compπses stoπng an identification of definition entities that are designated as removable.
7. Tangible medium carrying a computer program for performing a method for executing program code, said method compπses loading at least two definition entities into memory by a definition loading entity, said definition entity being associated to the definition loading entity, the method further compπses creating objects according to said definition entity, characteπzed in that the method compπses removing from memory, definition entities having no related objects, said definition loading means being associated with definition entities still having related objects
8. Tangible medium according to claim 7, characteπzed in that the method compπses designating definition entities as removable, removing from memory definition entities having no related objects when the definition entity is designated as removable, and in that the method compπses removing from memory definition entities associated with only definition entities having no related objects.
9 Tangible medium according to claim 8, characteπzed in that said method compπses stoπng an identification of definition entities that are designated as removable
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99966997A EP1068572A2 (en) | 1999-01-06 | 1999-12-20 | Arrangement for executing program code with reduced memory requirements |
| CA002322950A CA2322950A1 (en) | 1999-01-06 | 1999-12-20 | Arrangement for executing program code with reduced memory requirements |
| BR9908574-7A BR9908574A (en) | 1999-01-06 | 1999-12-20 | System and process for executing program code, and tangibly supporting a computer program to perform said process |
| KR1020007009841A KR20010083781A (en) | 1999-01-06 | 1999-12-20 | Arrangement for executing program code with reduced memory requirements |
| JP2000592737A JP2002534737A (en) | 1999-01-06 | 1999-12-20 | Apparatus for executing program code with reduced memory requirements |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99200015 | 1999-01-06 | ||
| EP99200015.8 | 1999-01-06 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| WO2000041079A2 true WO2000041079A2 (en) | 2000-07-13 |
| WO2000041079A3 WO2000041079A3 (en) | 2000-11-02 |
Family
ID=8239783
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP1999/010301 WO2000041079A2 (en) | 1999-01-06 | 1999-12-20 | Arrangement for executing program code with reduced memory requirements |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US6681381B1 (en) |
| EP (1) | EP1068572A2 (en) |
| JP (1) | JP2002534737A (en) |
| KR (1) | KR20010083781A (en) |
| CN (1) | CN1139032C (en) |
| BR (1) | BR9908574A (en) |
| CA (1) | CA2322950A1 (en) |
| WO (1) | WO2000041079A2 (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003012637A2 (en) * | 2001-07-31 | 2003-02-13 | Sun Microsystems, Inc. | Two tier clusters for representation of objects in java programming environments |
| GB2405506A (en) * | 2003-08-25 | 2005-03-02 | Samsung Electronics Co Ltd | Benchmarking Garbage Collection in Java Virtual Machines |
| EP1530131A2 (en) | 2003-11-05 | 2005-05-11 | Giesecke & Devrient GmbH | Accelerated reference finding for an automatic garbage collection |
| US7082597B2 (en) | 2001-06-20 | 2006-07-25 | Sun Microsystems, Inc. | Representation of objects in a Java programming environment |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2376191T3 (en) * | 2000-05-25 | 2012-03-09 | Oracle America, Inc. | METHOD AND APPARATUS FOR CREATING EFFECTIVE NATIVE METHODS THAT EXTEND A BYTE CODE INTERPRETER. |
| US7114152B2 (en) * | 2002-01-08 | 2006-09-26 | International Business Machines Corporation | Method, apparatus, and program to determine the mutability of an object at loading time |
| JP2005018425A (en) * | 2003-06-26 | 2005-01-20 | Matsushita Electric Ind Co Ltd | Program conversion method, program and storage medium |
| US7263532B2 (en) * | 2003-09-23 | 2007-08-28 | Microsoft Corporation | Region-based memory management for object-oriented programs |
| US7823137B2 (en) * | 2004-10-21 | 2010-10-26 | International Business Machines Corporation | Process and implementation for using byte code insertion to modify a class definition to define and use probes for application components |
| WO2007076629A1 (en) * | 2005-12-30 | 2007-07-12 | Intel Corporation | Type checking for object-oriented programming languages |
| US20090199171A1 (en) * | 2006-03-01 | 2009-08-06 | Nokia Corporation | Code Size Reduction by Outlining Specific Functions in a Library |
| US8375373B2 (en) * | 2010-04-19 | 2013-02-12 | Microsoft Corporation | Intermediate language support for change resilience |
| JP6010961B2 (en) * | 2012-03-27 | 2016-10-19 | 日本電気株式会社 | Data reference source identification system, identification method thereof, and computer program thereof |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3294326B2 (en) * | 1992-07-09 | 2002-06-24 | 株式会社日立製作所 | Data processing method and device |
| US5729710A (en) * | 1994-06-22 | 1998-03-17 | International Business Machines Corporation | Method and apparatus for management of mapped and unmapped regions of memory in a microkernel data processing system |
| US5925100A (en) * | 1996-03-21 | 1999-07-20 | Sybase, Inc. | Client/server system with methods for prefetching and managing semantic objects based on object-based prefetch primitive present in client's executing application |
| US6134602A (en) * | 1997-09-24 | 2000-10-17 | Microsoft Corporation | Application programming interface enabling application programs to group code and data to control allocation of physical memory in a virtual memory system |
-
1999
- 1999-12-20 CN CNB998035068A patent/CN1139032C/en not_active Expired - Fee Related
- 1999-12-20 KR KR1020007009841A patent/KR20010083781A/en active IP Right Grant
- 1999-12-20 JP JP2000592737A patent/JP2002534737A/en active Pending
- 1999-12-20 BR BR9908574-7A patent/BR9908574A/en not_active IP Right Cessation
- 1999-12-20 WO PCT/EP1999/010301 patent/WO2000041079A2/en not_active Application Discontinuation
- 1999-12-20 CA CA002322950A patent/CA2322950A1/en not_active Abandoned
- 1999-12-20 EP EP99966997A patent/EP1068572A2/en not_active Withdrawn
-
2000
- 2000-01-05 US US09/475,568 patent/US6681381B1/en not_active Expired - Fee Related
Non-Patent Citations (3)
| Title |
|---|
| SUN MICROSYSTEMS, INC.: CLARIFICATIONS AND AMENDMENTS TO THE JAVA LANGUAGE SPECIFICATION, [Online] 4 May 1998 (1998-05-04), XP002143375 Retrieved from the Internet: <URL:HTTP://JAVA.SUN.COM/DOCS/BOOKS/JLS/UN LOADING-RATIONALE.HTML> [retrieved on 2000-07-24] * |
| SUN MICROSYSTEMS, INC.: JAVA DEVELOPER CONNECTION TECH TIPS", [Online] 3 September 1997 (1997-09-03), XP002143402 Retrieved from the Internet: <URL:HTTP://DEVELOPER.JAVA.SUN.COM/DEVELOP ER/TECHTIPS/1997/TT0903.HTML#TIP2> [retrieved on 2000-07-25] * |
| VENNERS, BILL: "Under The Hood: Java's Garbage Collected Heap" JAVAWORLD, [Online] August 1996 (1996-08), XP002143401 Retrieved from the Internet: <URL:http://www.javaworld.com/javaworld/jw -08-1996/jw-08-gc_p.html> [retrieved on 2000-07-25] * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7082597B2 (en) | 2001-06-20 | 2006-07-25 | Sun Microsystems, Inc. | Representation of objects in a Java programming environment |
| WO2003012637A2 (en) * | 2001-07-31 | 2003-02-13 | Sun Microsystems, Inc. | Two tier clusters for representation of objects in java programming environments |
| WO2003012637A3 (en) * | 2001-07-31 | 2004-09-23 | Sun Microsystems Inc | Two tier clusters for representation of objects in java programming environments |
| US7036120B2 (en) | 2001-07-31 | 2006-04-25 | Sun Microsystems, Inc. | Two tier clusters for representation of objects in Java programming environments |
| GB2405506A (en) * | 2003-08-25 | 2005-03-02 | Samsung Electronics Co Ltd | Benchmarking Garbage Collection in Java Virtual Machines |
| EP1530131A2 (en) | 2003-11-05 | 2005-05-11 | Giesecke & Devrient GmbH | Accelerated reference finding for an automatic garbage collection |
| EP1530131A3 (en) * | 2003-11-05 | 2008-01-09 | Giesecke & Devrient GmbH | Accelerated reference finding for an automatic garbage collection |
Also Published As
| Publication number | Publication date |
|---|---|
| US6681381B1 (en) | 2004-01-20 |
| CN1292119A (en) | 2001-04-18 |
| JP2002534737A (en) | 2002-10-15 |
| EP1068572A2 (en) | 2001-01-17 |
| KR20010083781A (en) | 2001-09-01 |
| CA2322950A1 (en) | 2000-07-13 |
| WO2000041079A3 (en) | 2000-11-02 |
| CN1139032C (en) | 2004-02-18 |
| BR9908574A (en) | 2000-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100864192B1 (en) | Method and device for creating and using pre-internalized program files | |
| CN108139896B (en) | Extended virtual machine instruction set architecture | |
| US6757890B1 (en) | Methods and apparatus for enabling local Java object allocation and collection | |
| US6272674B1 (en) | Method and apparatus for loading a Java application program | |
| US6820101B2 (en) | Methods and apparatus for optimizing garbage collection using separate heaps of memory for storing local objects and non-local objects | |
| WO2000041079A2 (en) | Arrangement for executing program code with reduced memory requirements | |
| US11249758B2 (en) | Conditional branch frame barrier | |
| US6584478B1 (en) | Transparent garbage collection of resources | |
| JPH0644085A (en) | Method and device for executing access and computer system | |
| US8042103B2 (en) | Pre-translated files used in a virtual machine | |
| US20070203959A1 (en) | Apparatus and method for managing resources using virtual ID in multiple Java application environment | |
| EP1489518B1 (en) | Embedded garbage collection | |
| CN106980516B (en) | Information processing apparatus and resource management method | |
| Agesen et al. | Finding references in Java stacks | |
| EP1489492A1 (en) | Two-step instruction resolution | |
| MXPA00008635A (en) | Arrangement for executing program code with reduced memory requirements | |
| Tools | StackwalkerAPI Programmer’s Guide | |
| CN107153554B (en) | Information processing apparatus and library management method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WWE | Wipo information: entry into national phase |
Ref document number: 99803506.8 Country of ref document: CN |
|
| AK | Designated states |
Kind code of ref document: A2 Designated state(s): BR CA CN JP KR MX |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 1999966997 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: PA/a/2000/008635 Country of ref document: MX |
|
| ENP | Entry into the national phase |
Ref document number: 2322950 Country of ref document: CA |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 1020007009841 Country of ref document: KR |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| AK | Designated states |
Kind code of ref document: A3 Designated state(s): BR CA CN JP KR MX |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
| WWP | Wipo information: published in national office |
Ref document number: 1999966997 Country of ref document: EP |
|
| WWP | Wipo information: published in national office |
Ref document number: 1020007009841 Country of ref document: KR |
|
| WWR | Wipo information: refused in national office |
Ref document number: 1020007009841 Country of ref document: KR |
|
| WWW | Wipo information: withdrawn in national office |
Ref document number: 1999966997 Country of ref document: EP |