KR100631782B1 - Efficient Memory Management Method and Device in Object-Oriented Application - Google Patents

Abstract

The present invention relates to an efficient memory management method and apparatus in an object-oriented application.

An efficient memory management method in an object-oriented application according to an embodiment of the present invention comprises the steps of: receiving a signal for requesting memory allocation to an object, receiving information about an application configured by the object from the application manager; Allocating memory to an object and storing information about the application and location information of the memory allocated to the object.

Object Oriented, Garbage Collection, Exlets, Applets, Memory

Description

Method and apparatus for effective memory management in object-oriented application

1 is a block diagram showing an operation step of an exlet according to an embodiment of the present invention.

2 is a block diagram showing the configuration of a conventional memory manager and application manager.

3 is an exemplary view illustrating a process in which an exlet is destroyed after an object of the exlet according to the prior art is allocated to a memory.

4 is a block diagram illustrating interaction between a memory manager and an application manager according to an exemplary embodiment of the present invention.

5 is a flowchart illustrating a process of allocating a memory to an object according to an embodiment of the present invention.

6 is a flowchart illustrating a process of recovering a memory when an object is destroyed according to an embodiment of the present invention.

7 is an exemplary view showing object allocation according to an embodiment of the present invention.

8 is an exemplary view illustrating resource removal according to an embodiment of the present invention.

9 is an exemplary view showing the number of memory areas according to an embodiment of the present invention.

10 is a block diagram illustrating a configuration of a memory manager and a memory according to an embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

100: system 120: memory manager

140: application manager

Object-Oriented Programming is a method of developing computer programs that is based on data rather than objects and logic rather than operations. In the past, programs were traditionally dominated by a logical view: taking input, processing it, and then producing results. Programming was also considered as how to write logic rather than how to define data.

However, object-oriented programming is approached from the point of view of what is important in the program is the object to be handled rather than the logic. Examples of objects include people (depicted by name, address, etc.) to buildings, and stores for merchandise (characteristics can be described and manipulated), such as buttons and scrollbars that are tiny elements of the computer desktop. It all covers

The first step in object-oriented programming is to identify all the objects you want to deal with and how they relate to each other-often called data modeling. Once you have identified all objects, you generalize them to an object class and define the kind of data it contains and all the logical sequences that can handle it.

The logical order is called a method, and the actual instance of a class is called a "object" or, in some situations, a "class activator". An object or activator is what is actually performed in a computer. Methods define computer instructions, and the properties of class objects define related data.

Smalltalk is one of the first object-oriented programming languages, and C ++ and Java are the most popular object-oriented programming languages in recent years. In particular, Java is designed to be used for distributed applications in the enterprise and on the Internet. Java also runs on the Java virtual machine, allowing programs to operate independently of the system's hardware. As a result, Java serves as a leading application in many different digital devices or is embedded and functioning.

Advances in computing power and digital civilization have made programs that have been limited to conventional computer systems run on a variety of digital devices. In particular, with the development of multimedia and digital broadcasting, research on digital TV and mobile phones is increasing. Digital TVs, mobile phones, etc. require the implementation of many functions while receiving multimedia and also interacting with the user. In the case of digital TV, in order to implement interactive TV, an interface with a user is required. To this end, applets, components, and distributed objects such as Java, C ++, and Common Object Request Broker Architecture (CORBA) are running on digital devices.

Meanwhile, memory management is required to execute the application programs such as the object-oriented component or the applet. The above application programs are frequently loaded and destroyed in the case of computers, mobile phones, and digital TVs. In this case, it is necessary to quickly convert a memory that is no longer used into available memory. To do this, there is a garbage collection. However, garbage collection requires the retrieval and conversion of the entire memory, which is inefficient on systems with frequent object creation and destruction. In addition, devices such as digital TVs or mobile phones are often limited in size compared to computers, and thus, there is a need for a method of efficiently managing memory in executing an object-oriented program.

An object of the present invention is to increase the efficiency of memory management in executing an object-oriented program.

Another technical problem of the present invention is to allocate the memory to an object so that the application can be distinguished in the execution of an object-oriented program so that the memory occupied by the object can be quickly obtained when the application is later destroyed.

The objects of the present invention are not limited to the above-mentioned objects, and other objects that are not mentioned will be clearly understood by those skilled in the art from the following description.

The present invention relates to an efficient memory management method and apparatus in an object-oriented application.

An efficient memory management method in an object-oriented application according to an embodiment of the present invention comprises the steps of: receiving a signal for requesting memory allocation to an object, receiving information about an application configured by the object from the application manager; Allocating memory to an object and storing information about the application and location information of the memory allocated to the object.

According to another aspect of the present invention, there is provided an efficient memory management method of an object-oriented application, when an object-oriented application is destroyed, receiving a signal indicating the destruction of the application, and determining a memory area allocated to an object constituting the application. Reviewing, and recovering the memory area to available memory.

An efficient memory management apparatus in an object-oriented application according to an embodiment of the present invention may include: an object information receiver configured to receive a signal for requesting memory allocation for an object and to receive information about an application configured by the object from an application manager; An application memory manager configured to store and manage the received information; and a memory allocation manager configured to allocate memory to the object, wherein the application memory manager stores information about the application and location information of the memory allocated to the object. .

The terms used in the present specification are summarized as follows.

ActiveX Control

ActiveX controls can be written in any programming language that supports Microsoft's Component Object Model (COM). ActiveX controls are components or independent programs that can be created and reused by many applications on a single computer or distributed network. Support for distributed environments in COM is specifically called the distributed component object model (DCOM). In terms of the actual implementation of ActiveX controls, it's a type of DLL module that runs inside an application with a COM program interface called a "container." Approaches that use reusable components contribute to shortening the development time of the application and improving the program's functionality and quality. Application development tools for Windows 95 / NT, such as PowerBuilder and Microsoft Access, take advantage of these ActiveX controls. Visual Basic and C ++ are widely used to create OCX or ActiveX controls.

- Java

Java is a programming language designed to be used in the distributed environment of the Internet. Java looks like a C ++ language, but it is simpler to use than C ++ and enhances the full object-oriented nature of programming. Java can be used to create applications that run on a single computer or in a distributed client / server environment on a network. It can also be used to create small application modules or applets that are used as part of a web page. Applets allow users to interact with web pages.

Java applications

A Java application is a program that runs on a Java Virtual Machine using Java objects. Java applications include applets, Xlets, and middlelets.

Applet

A Java applet is a Java program embedded in an HTML page that can be executed by a Java-compatible web browser. The Java applet code on the web server side when a Java-compatible web browser displays an HTML page containing a Java applet. After downloading it, it runs in a specific area within the browser.

Applets are embedded applications that run in a web browser. The applet is closely related to the web page it contains because it provides the area where the applet is displayed on the page on which it is running.

There are four states in the applet life-cycle: Loaded, Stopped, Started, and Destroyed. The loading state means that an applet instance has been created but not yet initialized, and the suspended state is that the applet has been initialized but not running. Startup means that the applet is active, and destruction means the applet is terminated, and the applet instance returns all resources and waits for garbage to be reclaimed by garbage collection.

Midlet

The middlelet is a Mobile Information Device Profile (MIDP) application. Unlike applets, middlelets are not managed by web browsers, but by software specifically designed to control applications loaded on interactive pages or mobile phones. If a call comes in while the application is running, the call should not be interrupted by the application. In this case, therefore, such external management is appropriate for applications running on the wireless device.

The middlelet has three states: paused, active, and destroyed. In the middlelet, there is no state corresponding to applet loading.

Xlet

Exlets were originally part of the Java TV API, but are used by the Personal Basis Profile (PBP) and its superset, the Personal Profile (PP). When destroyed, the exit is terminated, returning used resources and waiting to be garbage collected.

Garbage Collection

Garbage refers to a portion of memory allocated to a program or an application that is no longer used. For example, if a memory is allocated to an object but the object is destroyed, then the memory is kept in use unless the memory is set as useful. Therefore, memory that is not used and cannot be used is called garbage, and the system needs to convert such garbage back into useful memory, which is called garbage collection or garbage collection.

Garbage collection consists of largely indicating garbage and converting garbage back into useful memory.

Java applications are applied to many systems. This applies to computer systems or to electronics such as digital TVs. Digital TV is a combination of the Internet and multimedia, also known as Interactive TV. Java applications are used in computers, digital TVs, mobile phones, etc. to interact with users and to apply various systems. Java applets, exlets, middlelets, etc. are suitable for these products.

These Java applets, exlets, middlelets, and activeX controls vary depending on the application system, implement object-oriented applications, and improve user convenience and interoperability in various electronic products. In the present specification, it will be described with an emphasis on these, but this is an embodiment of the present invention, the scope of the present invention includes the above-described applet and the middlelet, activex control, etc. and various electronic products or digital devices It is targeted at object-oriented applications based on objects running independently or embedded in. In addition, objects or components in CORBA, controls or components in C ++ are all examples of such object-oriented applications. However, the present specification will focus on Xlets, particularly among Java applications currently applied to various digital TVs.

The behavior of an application such as an Xlet is as follows:

1 is a block diagram showing an operation step of an exlet according to an embodiment of the present invention. In order to execute the exlet, a process of loading into memory 10 is required. Once loaded and initialized by initXlet (), it is ready for execution (20). Exlets loaded into memory mean that the objects that make up the exlet occupy a certain portion of memory, and the exlets manage their objects through heap-like data structures. The initialized exit is not yet active and must be started (30) to run. This can be done via startXlet () on an initialized exlet. An active exlet can be paused with pauseXlet (). A suspended exlet simply stops working, and there is no significant change in occupying memory. The start 30 and initialization 20 steps can be changed many times. However, if you destroy this exlet (40) it can no longer be used. In order to use it again, it must go through the loading (10) step.

However, this destroyed exlet must return the memory it occupies so that other exlets or the system can use the memory. The memory occupied by an exlet includes the memory occupied by the objects that make up the exlet. There has been garbage collection in the past for memory reuse. Garbage collection requires a full memory check to see if it is available. Garbage collection can also occur in real time, depending on the system, or after some time. However, in real time, it is performed at regular intervals due to the burden of checking the entire memory.

Frequently loading and destroying may occur when an exlet, applet, or C ++ component is running on a digital TV, mobile phone, or computer for multimedia information or user convenience. However, if the memory occupancy of the objects constituting the application such as an extlet or applet is maintained for a certain period of time, it may cause a lot of problems in memory efficiency. To prevent this, if garbage collection is done in real time, each time each exlet or applet is destroyed, the entire memory must be retrieved and garbage collected, which is inefficient in terms of system performance and time.

2 is a block diagram showing the configuration of a conventional memory manager and application manager. The application manager 140 is responsible for creating, initializing, and destroying applications. An application refers to an object-oriented application as described above, and refers to an exlet, applet, middlelet, C ++ component, or the like.

The memory manager 120 allocates memory to the object when the object is created. During garbage collection, the memory allocated to objects belonging to applications such as destroyed axlets and applets are cleaned up and set as useful memory. However, this does not happen dynamically in conjunction with the destruction of the exlets and applets as described above, but allows the memory manager to independently perform garbage collection after a certain period of time after the destruction of the exlets. . Even if garbage collection is performed every time the extlet disappears, the above-mentioned performance problem occurs in the above-described time.

Therefore, there is a difficulty to search the entire memory in order to recycle the memory after the destruction of the exlet, etc. Also, in order to avoid frequent searches, if the garbage collection is performed after a certain period of time, the memory cannot be used by other objects without being used. Will be present. Thus, unused memory, or garbage, can affect system performance. Particularly in digital devices with frequent execution and destruction of applications, the presence of such garbage memory can degrade the overall performance of the system.

3 is an exemplary view illustrating a process in which an exlet according to the prior art is allocated to a memory and then destroyed.

Figure 3 (a) shows a case in which the excit A is loaded. In the loading phase, the objects contained in Xlet A make up the heap. And when these exlets A are loaded into memory to access resources for a common memory area, the memory of the common memory area may also constitute a heap. While occupying a portion of memory, exit A can be activated and stopped. The same applies to exit B. Here, Axle A and Axle B use the same heap area, and there is no distinction between the memory areas occupied by Axle A and Axle B.

(b) shows the case where Exlet A is destroyed. Exlets are destroyed and can no longer be used, but the memory area occupied by the objects that make up Exlet A remains intact. As a result, this area is not available to any new objects or exits or systems. Of course, if garbage collection is performed in step (c) to use the memory area, the memory area 81 may be used again by another system or an exit. However, in order to collect the memory in step (c), it is inconvenient to search for the entire memory heap, and to check whether any memory is in use and convert the memory into available memory.

In addition, longer time between steps (b) and (c) reduces the amount of available memory. Therefore, there is a need for a method and apparatus for allocating memory to a memory unit based on a unit loaded in the memory, such as an exlet, and destroying the memory while reducing the search of the entire memory.

(A), (b), and (c) of FIG. 3 show objects visually aligned in a memory space. However, it is not necessarily classified physically, but can be visually linked even when physically mixed.

4 is a diagram illustrating an interaction between the memory manager 120 and the application manager 140 according to an exemplary embodiment of the present invention.

The application manager 140 is responsible for creating and destroying applications such as exlets and applets, and the memory manager 120 allocates memory to objects. Before allocating memory to an object, the memory manager 120 asks the application manager 140 which object or object the object belongs to. When the application manager 140 knows an application such as an exlet or applet that is the owner of the object, the memory of the object is allocated to a memory area (for example, a memory heap) allocated to the application (for example, an exlet). do. If you create and manage sub heaps by the unit of an exlet or by application, such as a component or applet, when the exlet or component is destroyed, the memory area occupied by the objects constituting these applications can be recovered and reused. Can be. Using the subheap is an embodiment, and in addition, the memory may be configured to track an object belonging to specific applications. This may be divided into a specific memory region in a physical configuration, but through a logical configuration, even physically distributed objects can be configured to exist together in the logical region. This may be a linked list, various trees, that is, a binary tree or a B-tree, in addition to the sub-heap shown in the above example. Of course, it is also possible to configure using a hash table, it may be made by configuring a small table that stores the location information of each object, rather than the link. Such an implementation may vary depending on the characteristics of the system or application, and the memory may be managed by selecting an optimal structure for the system. The application manager 140 may be an exlet manager, an applet manager, or a component manager.

5 is a flowchart illustrating a process of allocating a memory to an object according to an embodiment of the present invention.

The memory manager 140 is requested to allocate memory to the object (S102). The memory manager 140 receiving the request inquires of an application manager of which application (exlet, applet, component, etc.) the object owns (S104). The application manager receiving the inquiry sends information about the corresponding application (exlet, applet, component, etc.) to the memory manager 140. The memory manager 140 receiving information on which application the object composes allocates the memory of the requested object to the sub heaps allocated to the objects configuring the application (S106). Through these processes, objects owned by the exlet are stored on the same subheap.

Allocating an object to a specific memory area, that is, the sub heap in the above example, may mean allocating arbitrary memory to the object and associating the memory location information with the sub heap. This means one embodiment that is physically mixed but logically connected. You can also allocate physically distinct memory regions for specific applications. This means that objects constituting an application are stored in a cluster. Allocating a memory area in this specification means both the above physical or logical connections.

FIG. 5 configures a sub-heap of an object for each application, that is, for each of an exlet or an applet, so that when an application such as an exlet or an applet is later destroyed, the object can be easily tracked to use memory. Using a subheap is an embodiment, and various data structures such as a link list or a tree may be used instead of the subheap.

6 is a flowchart illustrating a process of recovering a memory when an application is destroyed according to an embodiment of the present invention. The application manager terminates the application A (S122). This can happen if an exit or applet is destroyed. In addition to the termination, the application manager requests the memory manager to recover the memory area occupied by the application A while performing a resource removal operation that is not removed by the application A such as an axlet or an applet (S126). The memory manager examines the sub-heap that is the memory area allocated to the application A, and obtains information on which memory area the application A occupies (S127). The memory manager retrieves the entire memory area of the application A configured as the sub heap through the review and initializes it (S128). When the application A destruction process is completed through the memory recovery, the process returns to the original execution flow (S130).

The application in FIG. 6 is an object oriented application such as an Xlet, an applet, a middlelet, a C ++ component, and the subheap is an embodiment for easily tracking the objects allocated for each application.

7 to 9 are block diagrams illustrating a process of recovering a memory when an object constituting a specific application or shared objects through the system is allocated memory while constituting a memory sub heap in FIGS. 5 and 6, and the application is destroyed. It is also. In FIGS. 7 to 9, an exlet is an embodiment of an application, and objects constituting the application configure a memory through a sub-heap and track an object later by application. In addition to the sub-heap, the memory can be configured through the link list, and the object can be allocated to the memory for each application by using the tree structure.

7 is an exemplary view showing object allocation according to an embodiment of the present invention. Memory is allocated to the object by the process of FIG. 81, 82, and 83 are memory areas of the exit A, the exit B, and the exit C, respectively. 84 denotes objects of a system, that is, a common memory area. The memory manager allocates the objects owned by each exlet to the corresponding subheap, so the memory partitions between the exlets are divided logically or physically. 91 and 92 mean that Alet uses external or shared resources.

Although the memory space is visually divided in FIG. 7, it does not mean that the actual memory space is divided by application such as an exlet or an applet. That is, it may be configured to be logically distinguishable, or may be actually divided and stored for each application. In real memory, objects may be mixed regardless of the exit. However, these objects can form a separate link or heap so that they can be tracked by each exit. In data structures, links or heaps are logically linked and structured, not limited by physical addresses in memory.

8 is an exemplary view illustrating resource removal according to an embodiment of the present invention. It corresponds to steps S122 and S124 of FIG. 6. If Xlet A uses objects in the system area, it eliminates the use of external resources. This is done through the removal of 91, 92 of FIG. However, the memory area of Xlet A is in the form of a sub heap.

9 is an exemplary diagram illustrating the number of memory areas according to an embodiment of the present invention. As shown in FIGS. 7 and 8, the subheap is configured in an exlet or applet unit. And the memory manager keeps information about the subheap. Therefore, the memory area of the objects of the exlet A can be known by tracking the sub heap, and the memory constituting the sub heap can be converted into the available memory, thereby eliminating garbage.

10 is a block diagram illustrating a configuration of a memory manager and a memory according to an embodiment of the present invention.

The memory manager is largely comprised of an application memory manager, a memory allocation manager, and an object information receiver.

The application memory manager 122 includes a pointer to a memory sub heap occupied by an application and corresponding objects constituting the application. The pointer refers to location information of the memory. When the memory is allocated to an object constituting a specific application through this information, the application memory manager stores information that allows tracking of which object is stored in which memory location. As discussed above, this information can be made by configuring a sub-heap or using a link. You can allocate memory required by an object with or before or after this operation. When the application is destroyed, the objects in the application convert the memory allocated to the objects into usable memory according to the information of the application memory manager 122 to enable garbage collection. As described above, the application memory manager 122 functions to manage memory of objects included in an application such as an slit, applet, etc. and objects shared by various applications in a system for each application or system.

The memory allocation manager 124 allocates memory and collects garbage. When the object is requested to be allocated through the object information receiving unit 126, the application (exlet, applet, etc.) to which the object to be allocated belongs to the object of the corresponding application stored in the application memory manager 122 is examined. Find the memory sub heap and allocate objects. In addition, the garbage collection command from the Java virtual machine converts unused and occupied memory into available memory. Since the memory of the sub heap indicated by the expired exlet is garbage, the memory allocation management unit 124 may collect them and convert them into available memory.

The object information receiving unit 126 is a part that interacts with an application manager responsible for creating and destroying an application, such as an slit manager or an applet manager. When the memory allocation request for the creation of the object constituting the application is requested, the object information receiving unit 126 inquires which exlet or which applet the object is owned. The part which performs such exchange of information is an object information part.

The memory manager, that is, the memory management device, is included in all digital devices on which object-oriented applications such as Java, COVA, and C ++ run. In particular, with the recent increase in the need for object-oriented applications such as exlets in digital TV, the memory manager can efficiently manage the resources of the digital device.

Those skilled in the art will appreciate that the present invention can be embodied in other specific forms without changing the technical spirit or essential features of the present invention. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. The scope of the present invention is indicated by the scope of the following claims rather than the above description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents are included in the scope of the present invention. Should be interpreted.

By implementing the present invention, it is possible to increase the efficiency of memory management when executing an object-oriented program.

By implementing the present invention, it is possible to increase the reuse rate of memory in application units in allocating memory of objects.

Claims (17)

Receiving a signal requesting to allocate memory to an object constituting the application; Receiving information about an application configured by the object from an application manager; Allocating memory to the object; And And storing information about the application and location information of a memory allocated to the object. The method of claim 1, And information about the application includes an identifier of the application. The method of claim 1, The application may be any one of an sxlet, an applet, a middlelet, an activex control, a coba component, and a C ++ component. The method of claim 1, The allocating step includes connecting a memory area allocated to the object to a memory area allocated to a second object constituting the application. If the object-oriented application is destroyed, Receiving a signal indicating the disappearance of the application; Reviewing a memory area allocated to an object constituting the application; And And reclaiming the memory area into available memory. The method of claim 5, Reviewing the memory area includes finding information about the memory area that can be identified by the identifier of the application. The method of claim 5, The application may be any one of an sxlet, an applet, a middlelet, an activex control, a coba component, and a C ++ component. The method of claim 5, The retrieving may include adding a memory area allocated to an object constituting the application to the available memory area. An object information receiver configured to receive a signal requesting to allocate memory to an object constituting an application and to receive information about an application configured by the object from an application manager; An application memory manager configured to store and manage the received information; And A memory allocation management unit for allocating memory to the object; The application memory manager is an efficient memory management device for an object-oriented application for storing information about the application and location information of the memory allocated to the object. The method of claim 9, And information about the application includes an identifier of the application. The method of claim 9, And the application is any one of an sxlet, an applet, a middlelet, an activex control, a coba component, and a c ++ component. The method of claim 9, And a memory allocation management unit connects a memory region allocated to the object to a memory region allocated to a second object constituting the application. The method of claim 9, If the object-oriented application is destroyed, The object information receiving unit receives a signal indicating the disappearance of the application, The memory allocation management unit examines the memory area allocated to the object constituting the application in the application memory management unit and recovers the memory area to the available memory. The method of claim 13, Reviewing the memory area finds information about the memory area that can be identified by the identifier of the application. The method of claim 13, Recovering to the available memory is an efficient memory management apparatus for an object-oriented application, adding a memory area allocated to an object constituting the application to the available memory area. A recording medium having recorded thereon a computer readable program for performing the method of any one of claims 1 to 8. A system capable of running an object-oriented application comprising the memory management device of any one of claims 9 to 15.

Images