JP2002259146A - Device and method for executing application - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an application execution device capable of recovering resources without using kernels and a Java application execution device capable of continuously executing Java applications without restarting Java middleware and reducing the load of garbage collection processing. SOLUTION: In providing a resource at the request for providing a resource from an application, a library part acquires an identifier(ID) for identifying the application requesting for provision of the resource and stores a pair of the provided resource and the acquired ID in a table. At the end of the application, the library part acquires the application ID of the ended application, specifies the resource corresponding to the acquired ID from the table and releases the specified resource.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for executing, in an application execution apparatus, the recovery of resources that have become unnecessary due to the termination of an application.

[0002]

2. Description of the Related Art In a general application execution apparatus, a kernel of an operating system is provided with resources (memory,
Various devices such as keyboards).
Here, “collection” means that resources provided to the application by the operation system such as the kernel are returned from the application. The kernel stores a resource collection procedure for each device in order to perform resource collection. As a result, when the device used by the application becomes unnecessary, the kernel can collect the resources according to the collection procedure of the device, and can use the resources efficiently.

[0003] In a Java application execution apparatus, for example, in the case of a PC, with respect to collection of resources other than memory, Java middleware (so-called virtual machine) itself does not collect resources. The resource is recovered by the operation.
On the other hand, collection of memory is performed by "garbage collection" by Java middleware. "Garbage collection" refers to collecting unnecessary areas in the memory area. In Java, an application is loaded by loading each instance (hereinafter referred to as an object) of a plurality of classes constituting the application into a memory. The memory area is shared by objects that are loaded for the running application, and the memory areas are allocated in the order in which they are loaded. Therefore, when objects are continuously loaded into the memory area from a plurality of applications, each object loaded from one application is allocated to the memory area in a discontinuous manner. If the memory area is discontinuously occupied by the loaded object, garbage collection is performed to resolve the memory shortage.

[0004]

However, the technology of the resource recovery processing described above has the following problems. First, in the case of resource collection processing by the kernel in the application execution device, every time a new device is added to the application execution device, the procedure for collecting the added device must be newly stored in the kernel. There's a problem.

[0005] Second, in the case of resource collection processing in the Java application execution device, if the application is sequentially executed without terminating the Java middleware, the collection of resources other than memory by the kernel becomes
Since this is not performed until the Java middleware terminates, even if one application terminates, the resources provided to that application are not collected. Therefore, if the next application needs the same resources, the next application There is a problem that it cannot be executed.

Third, when a memory area allocated to an object in a discontinuous manner becomes unnecessary, there is a problem that a load of garbage collection of the memory area increases. In view of the above problems, the present invention provides an application execution device that executes resource recovery without using a kernel, without restarting Java middleware,
Can run Java applications continuously
An object of the present invention is to provide a Java application execution device, and to provide a Java application execution device in which the load of garbage collection processing is reduced.

[0007]

According to an aspect of the present invention, there is provided an application execution apparatus including at least one library unit for providing resources to an application and a kernel unit. The kernel unit has a notifying unit for notifying each library unit that has provided resources of the terminated application when the application is terminated, and each library unit terminates when notified from the notifying unit. A collection means for collecting resources provided to the application. Each means in the application execution device may be realized as a computer-readable recording medium that stores a program for causing a computer to realize the means.

Further, the application execution apparatus according to the present invention comprises an OS unit for providing resources to an application and a Java application.
An application execution device including a middleware unit, wherein the Java middleware unit includes a first table holding unit that holds a table indicating a correspondence between an application, a task corresponding to the application, and a thread configuring the task, and an instruction to end the application. Notification means for notifying which task is an application corresponding to the application to be terminated with reference to the first table holding means, and the OS unit executes a task for executing the application for each application. A task generating means for generating, a thread generating means for generating a plurality of application threads constituting the task, and executing the application threads to execute a program code of the application and to allocate resources requested by the application. Management means for holding a table indicating the correspondence between the provided resources and the tasks to which the threads belong, and resources corresponding to the tasks notified from the notification means specified by the management means and provided to the application. Collection means for collecting resources. Each means in the application execution device may be realized as a computer-readable recording medium that stores a program for causing a computer to realize the means.

An application execution apparatus according to the present invention is an apparatus for executing an application that requires garbage collection, wherein each time the application is started, a divided heap area acquiring unit acquires a divided heap area from a memory heap area. Allocating means for allocating the divided heap area acquired by the divided heap area acquiring means to the started application, and memory releasing means for releasing the divided heap area allocated to the application every time the application is terminated. It is characterized by having. The memory heap management method may be implemented by using each unit or the like in the application execution apparatus as a step, or may be realized as a computer-readable recording medium that records a program for causing a computer to execute the steps.

[0010]

DESCRIPTION OF THE PREFERRED EMBODIMENTS (Embodiment 1) In an application execution apparatus according to the present embodiment, a library unit, rather than a kernel unit, collects resources provided to an application each time the application ends. Here, the “application” indicates one of a program and a function of executing the program. "Resources" means tuner, MPEG audio decoder, MPEG video decoder, keyboard input device, remote control input device, mouse input device, trackball input device, mutex, semaphore, network device, serial device, IEEE13
94 (serial interface), USB (Universal Ser
ial Bus) Device interface, file system, display device, memory, modem, etc.
The library unit is a so-called device driver group that controls resources (secure, manage, and collect resources) in response to a request from an application. “Recovery” means that resources provided to the application by the operation system, such as the kernel, are returned from the application.

More specifically, the library unit obtains an identifier for identifying the application that has requested the provision of the resource when the resource is provided in response to the request for the provision of the resource from the application. The set of application identifiers set is held in a table. When the application ends, the application identifier of the terminated application is obtained, the resource corresponding to the obtained identifier is specified from the table, and the specified resource is collected.

An embodiment of the present application execution apparatus will be described below with reference to the drawings. FIG. 1 is a block diagram showing a configuration of the application execution device 10. The application execution device 10 includes an application input unit 11, an application storage unit 12, a kernel unit 13, a library storage unit 14, a device unit 15, and an instruction notification unit 16.

The application input unit 11 is composed of a floppy (registered trademark) disk drive, a CD drive, a network interface board, a broadcast receiving device, etc., receives an application to be executed, and stores it in the application storage unit 12. The application storage unit 12 includes a RAM, a ROM, a hard disk, a CD drive, a floppy disk, and the like, and stores an application output from the application input unit 11 or a pre-installed application.

The kernel unit 13 comprises a sequential execution unit 13a, a resource recovery notifying unit 13b, and an identifier providing unit 13c.
The application stored in the application storage unit 12 is executed. When the application to be executed is a binary program, the sequential execution unit 13a is configured by a CPU or the like that executes the binary program as it is. If the application to be executed is an intermediate code such as Java bytecode (Java is a trademark of Sun Microsystems, Inc. in the United States), the intermediate code is sequentially analyzed and executed by a module (virtual machine or interpreter) or the like. Be composed. The sequential execution unit 13a reads and executes an application stored in the application storage unit 12. Further, the application to be executed requests the library unit stored in the library storage unit 14 to provide resources, and receives the resource requested by the application from the library unit.

The resource recovery notifying unit 13b notifies the library unit which provides resources to the application every time the application is terminated, etc., with a resource recovery instruction and the application identifier. Specifically, the resource collection notifying unit 13b receives the registration of the callback function from the library unit stored in the library storage unit 14, and is registered when receiving the notification of the end or the interruption of the application from the instruction notifying unit 16. Calls and executes the callback function, and notifies the library unit of the identifier of the application.

Here, "registration of the callback function" means that the library unit responds to the request of the application by
When the provision of new resources to the application is started, the following information is obtained by calling the callback function to execute the callback function in the library section to determine which application has been suspended or terminated if the application is terminated or suspended. Requesting the resource collection notifying unit 13b to notify us. "

FIG. 2 shows an example of a C language program defining a callback function. CALLBACK # f indicates the type name of the callback function. This callback function has no return value and takes an integer value as an argument. FIG. 3 shows an example of a C language program in which registration, deletion, and execution of a callback function are described. Line numbers 6 to 14 show a registration program example, line numbers 16 to 20 show a deletion program example, and line numbers 22 to 26.
Shows an example of an execution program.

The identifier providing unit 13c provides an application identifier in response to a request from the library unit. The library storage unit 14 includes a plurality of library units 14a to 14n that control devices as resources. Each library unit controls a device corresponding to the device unit 15 (for example, the library unit 14a
The library unit 14b controls the device 15b. ). Actually, the library storage unit 14 is configured by a ROM or a hard disk, and in each library unit, a program that describes a function group for device control is called by an application and executed, whereby device control is realized. .

Specifically, each library unit controls resources by performing the following processing. The resource is provided according to the request of the application, and the resource collection notifying unit 13 is provided.
Register a callback function in b. Next, the application identifier of the application requesting the resource is acquired from the application identification unit 13c, and the acquired application identifier is stored in a table in combination with the resource name of the provided resource. Further, the registered callback function is executed by the resource release notifying unit 13b, and when the application identifier of the application using the resource to be collected is notified, the callback function corresponds to the application identifier notified from the held table. The resource name is specified, and the resource with the specified resource name is collected.

Next, a description will be given, with reference to FIG. 4, of a resource providing process performed by each library unit in response to an application request. FIG. 4 is a flowchart illustrating a resource providing process performed by each library unit. Each library section
Secure resources according to application requirements (S30
1), it is determined whether or not the callback function has already been registered (for example, a flag is set to determine registration / non-registration) (S302). If not registered (S302: N), the resource collection notification The callback function is registered in the unit 13b (S303).

Next, the identifier providing unit 13c is called to acquire the application identifier of the application which has requested the resource (S304), and the acquired application identifier and the resource name of the secured resource are set as a set and held in a table (S3).
05), providing resources to the application (S306). If registered (S302: Y), the processing of S304 to S306 is executed without newly registering the callback function.

FIG. 5 shows an example of the above table. FIG.
4 shows a table in which an application identifier and a resource name (file name) held by a library unit (hereinafter, referred to as a library unit F) that controls a file system are set.
FIG. 5A shows that the library unit F is the resource release notifying unit 13b.
And register the callback function in the file name "a.tx" for the application with the application identifier "1".
t "resource. When the application requests the provision of resources by calling the function of the library unit F, the library unit F secures the resource of the file name “b.txt” and acquires the application identifier “2” from the identifier providing unit 13c. . In this case, since the callback function of the library unit F has already been registered, it is not re-registered. The library unit F holds the acquired application identifier “2” and the file name “b.txt” of the secured resource as a set in a table, and FIG. 5- (2)
Update the table as shown in.

Next, the resource collection process performed by each library unit will be described with reference to FIG. FIG. 6 is a flowchart illustrating a resource collection process performed by each library unit. When the callback function is called, each library unit acquires the application identifier from the resource collection notifying unit 13b (S401), extracts one set of the application identifier and the resource name stored in the table (S402), and retrieves the extracted application identifier. And the application identifier acquired from the resource collection notifying unit 13b (S40).
3). If the application identifiers match, the resource of the resource name of the extracted set is collected (S404), the set is deleted from the table (S405), and the comparison with all the sets stored in the table has been completed. (S406: Y) ends the processing. For example, in the example of the table in FIG. 5- (2), when the acquired application identifier is “2”, the set of the file name “b.txt” corresponding to the application identifier “2” is deleted from the table ( FIG. 5- (3)). If comparison with all sets has not been completed (S406: N), the next set is taken out (S402), and the same processing is repeated (S403 to S403).
S406). If the application identifiers do not match,
If the comparison with all the sets held in the table has been completed (S406: Y), the processing ends. If comparison with all sets has not been completed (S406: N), the next set is taken out (S4
02), the same processing is repeated (S403 to S406).

The devices 15a to 15n are a memory, a display, an input device (keyboard, remote controller, etc.),
Including file systems, network devices, etc.
Each device operates according to control from an application performed through each library unit stored in the library storage unit 14. The instruction notifying unit 16 performs processing of starting, stopping, resuming, and terminating the application.

The process of starting the application means instructing the sequential execution unit 13a to execute the application stored in the application storage unit 12. The process of stopping the application refers to interrupting the application being executed by the sequential execution unit 13a and notifying the resource collection notifying unit 13b of the interruption of the application as necessary.

The process of resuming the application means instructing the sequential execution unit 13a to execute the suspended application. Application termination processing
This means instructing the sequential execution unit 13a to terminate the application being executed and notifying the resource collection notifying unit 13b of the termination of the application.

In the present embodiment, the application identifier notified to each library unit that provided resources to the application when the application is terminated or interrupted is:
Although the number is one, when a plurality of applications are simultaneously terminated, a plurality of application identifiers may be notified to each library unit. FIG. 7 shows a flowchart of the resource collection process performed by each library unit in this case. Each library unit obtains from the resource collection notifying unit 13b a plurality of application identifiers that provided the resources to be collected (S751), extracts one of the obtained application identifiers (S752), and sets the application identifier and the resource name stored in the table. Is retrieved (S753), the retrieved application identifier and the resource collection notifying unit 13
b to compare the application identifier obtained from
54). If the application identifier matches (S754:
Y) holds the corresponding resource name as the resource name to be collected (S755), deletes the set from the table (S756), and completes the comparison with all the sets stored in the table (S757). : Y) obtains the next application identifier (S758, S752) and repeats the same processing. When the comparison is completed for all the application identifiers acquired in S751 (S758: Y), the resources corresponding to the resource names held as the resource names to be collected in S755 are collectively collected (S7).
59).

Thus, the library section can effectively collect resources. For example, when all the resources managed by the (one) library unit are collected by terminating a plurality of applications, the resources can be quickly collected only by processing for initializing the management table. (Embodiment 2) In the first embodiment, the library unit registers a callback function to be called when the application is terminated or the like for each library unit. In the present embodiment, the callback function of the first embodiment Is generated, and the resource provided to the application is collected every time the application is terminated. Here, the “resource recovery instance” is a program generated from a class (a Java bytecode program) stored in the library unit and describing various types of information and a method that is a function for extracting the information. The collection instance holds information on the application that has requested the provision of the resource and the provided resource, and a method for extracting the information. By calling this method on the program, the stored information is retrieved.

Hereinafter, an embodiment of the present application execution apparatus will be described with reference to the drawings. FIG. 8 is a block diagram illustrating a configuration of the application execution device 20. The application execution device 20 includes an application input unit 11, an application storage unit 12, and an OS unit 2.
3, a library storage unit 24, a device unit 15, and an instruction notification unit 16. Application input unit 11,
The application storage unit 12, the device unit 15, and the instruction notification unit 16 are the same as those included in the execution device 10 according to the first embodiment, and a description thereof will be omitted.

The OS unit 23 includes a virtual machine unit 23a,
The application management unit 23b executes a Java application (hereinafter referred to as an application) stored in the application storage unit 12. The virtual machine unit 23a loads the application from the application storage unit 12, sequentially analyzes the bytecode of the application, and executes the application. Further, each device stored in the device unit 15 is controlled via each library unit stored in the library storage unit 24. Actually, an application executed by the virtual machine unit 23a calls a class of each library unit which is a program describing device control,
The control of each device is realized by executing the class program.

The application management unit 23b manages an application that is being executed.
Has a function corresponding to the identifier providing unit 13c. Specifically, the application management unit 23b generates an instance for executing a process for each application from a class that defines a process for storing application information,
In each generated instance (here, called an application information instance), an application identifier of each application being executed is stored, and each generated application information instance (2 in FIG. 8) is stored.
3c to 23e) to manage the application being executed. Further, when each library unit is requested by an application to provide resources, the library unit provides an application information instance as an identifier for specifying the requested application. Here, instead of storing the identifier of each application in each application information instance, the application information instance itself may be used as the identifier of the application.

Each application information instance is:
It has a function corresponding to the resource collection notification unit 13b of the first embodiment. Specifically, the following processing is performed. Each application information instance receives registration of a resource recovery instance from each library unit. Here, the “registration of the resource recovery instance” means that when the library unit provides a new resource to the application, “if the application is terminated or suspended in the library unit,
Requesting the application information instance that stores the application identifier to notify which application it is ". The above notification is executed by calling a method implemented in the resource recovery instance generated at the time of registration. A resource recovery instance is generated from each class stored in each library unit as shown below. Each class implements the method defined by the “interface” by implementing the “interface”. An "interface" defines a method to be implemented in a class. FIG. 9 is an example of this interface. In this example, ResourceCollectionListener interface defines update method. By implementing this interface, each class stored in each library section prepares a class that describes resource recovery processing in the update method, and a resource recovery instance that implements the interface is generated from the prepared class, and application information The resource recovery instance generated for the instance is registered. By this processing, it is guaranteed that the generated resource recovery instance has implemented the method defined by the interface (here, the update method), and the above notification is executed by calling the method defined by this interface Is done.

When the application is terminated or interrupted, the application information instance storing the application identifier is stored in a method (in this case, up
The above method is notified to the library section that provides resources to the application by calling the date method).

Further, the application information instance may store a method for deleting the registered resource recovery instance or a method for knowing the state of the application. FIG. 10 shows an example of a class for generating an application information instance storing the above method. In FIG. 10, it is a class for generating an application information instance.
applicationPropoxy is the application name (applicati
onName), getStatus method to know the status of the application, addListe to register the resource collection instance (resourceCollectionLister)
ner method, delete resource registration instance registration r
emoveListener method is defined.

The library storage unit 24 includes a plurality of library units 24a to 24n. Each library unit controls the devices 15a to 15n of the device unit 15, and performs a process of providing a device as a resource and a process of collecting the provided resource in response to a request from an application. Actually, the library storage unit 24 is configured by a ROM or a hard disk. In each library unit, a program described in a class group, which is a device control program, is called by an application and executed, so that device control is performed. Has been realized.

First, the resource providing process will be described.
Each library unit, when requested to provide resources from the application, provides the requested resource to the application, calls the application management unit 23b, acquires an application information instance corresponding to the application, and obtains the resource information from the resource collection class. A collection instance is generated, and the generated resource collection instance is registered in the application information instance. Further, each library unit sets the resource name of the provided resource and the application information instance as a set and holds the set in the resource collection instance.

FIG. 11 shows an example of the resource recovery class. In FIG. 11, a resource collection class for controlling the file system is defined. Specifically, it is called at the time of termination or interruption of the application, information of internal variables app (corresponding to the application information instance) and name (corresponding to the file name of the resource) called "fields" created when the resource recovery instance is generated. In this case, an update method for executing resource collection processing is defined. FIG. 12 shows an example of a resource collection instance generated by the resource collection class of FIG. Reference numeral 901 denotes an instance table holding a resource collection instance;
2, 903 indicates a generated resource recovery instance. FIG. 12- (1) shows a resource collection information instance 90.
2 provided the resource name (here, the file name "a.tx
t ”) and an application information instance (here,“ 1 ”) as a set. FIG. 12- (2) shows resources (file name “b.txt”) assigned to an application whose library is managed by another application information instance “2” different from that of FIG. 12- (1).
File) and a new resource recovery instance 9
03 is generated.

Hereinafter, the resource providing process will be described in more detail with reference to FIG. FIG. 13 is a flowchart illustrating a resource providing process performed by each library unit. When each application is requested to provide resources by an application, each library reserves resources in response to the request (S1001) and acquires an application information instance corresponding to the application from the application management unit 23b (S1).
002). Next, one of the held resource collection instances is extracted (S1003), and the application information instance acquired from the application management unit 23b is compared with the application information instance held in the extracted resource collection instance (S1004). When the application information instances match (S1004: Y)
Holds the resource name of the secured resource in the resource collection instance that holds the application information instance (S1005), and provides the secured resource to the application (S1009). On the other hand, in S1004, if the application information instances do not match (S1004: N), the application information instances are compared with all other held resource recovery instances (S1006), and there is no match. If (S1006: Y), a new resource recovery instance is generated, and the generated resource recovery instance holds the application information instance acquired from the application management unit 23b and the resource name of the secured resource as a set (S1007). The generated resource recovery instance is registered in the application information instance corresponding to the application that has requested the resource reservation (S1008), and the reserved resource is provided to the application (S1009).

Next, resource recovery processing will be described. When the method of the corresponding resource recovery instance is called from the application information instance that stores the application identifier when the application is terminated or suspended, the library unit recovers the resource corresponding to the resource name held in the resource recovery instance. In the above case, a description will be given of a resource collection process when a method for knowing the state of an application (hereinafter referred to as an application state method) and a method for deleting the registration of the resource collection instance are prepared in the application information instance. FIG. 14 is a flowchart illustrating a collection process performed by the library unit when the application information instance has an application state method. When the method of the resource recovery instance registered from the application information instance is called, the library unit calls the application state method of the application information instance held in the resource recovery instance, and determines whether the application has been suspended or terminated. Acquisition (S1101), it is determined whether or not to collect resources based on the acquired information (S1102).
The resource corresponding to the resource name held in the resource collection instance is collected (S1103), a method for deleting the registration of the resource collection instance is called, and the resource collection instance is released by executing the method. (S1104).

Note that the determination in S1102 may be a determination that some specific resources are to be collected instead of all resources used by the application. In this case, the release of the resource collection instance in S1104 is performed when all the resources have been collected. (Embodiment 3) The application execution apparatus according to the present embodiment generates a thread for each application, secures a resource requested by the application with the generated thread, and provides a resource provided to the terminated application each time the application ends. Release of unnecessary resources by the OS unit by the task unit associated with the created thread, enabling execution of the next application without terminating Java middleware (so-called virtual machine) Things. Here, the “thread” is a context (a flow of a series of processes) for sequentially executing the program code of the application. An application written in Java can generate a plurality of threads, and each thread can execute the application program code in parallel. In the present embodiment, a “task” is a set of a plurality of threads that execute an application. In this embodiment, the resources allocated to the application are:
It is managed in association with this “task”.

Hereinafter, embodiments of the present application execution apparatus will be described in detail with reference to the drawings. FIG.
3 is a block diagram illustrating a configuration of the application execution device 30. The application execution device 30 includes an application input unit 11, an application storage unit 12,
Java middleware section 33, OS section 34, hardware section 3
5. An instruction notification unit 36 is provided. The application input unit 11 and the application storage unit 12 correspond to the first embodiment.
Are the same as those included in the execution device 10 of FIG.

The Java middleware unit 33 includes a VM (virtual machine) unit 33a, an application management unit 33b, and a class library storage unit 33c, and executes an application stored in the application storage unit 12. The VM unit 33a executes an application. Specifically, the VM unit 33a performs the following processing. The application described in the bytecode is sequentially translated into a binary code executable by the CPU 35a included in the hardware unit 35, and the translated binary code is executed by the CPU 35a.

The VM unit 33a secures resources necessary for its own operation and application execution. Specifically, the VM unit 33a calls each class library unit included in the class library storage unit 33c, and secures resources necessary for its own operation via each class library unit. Further, when the application requests to secure resources during execution of the application, the class library storage unit 33
Call each class library section included in c, and secure resources requested by the application via each class library section.

When the application requests deletion of the thread whose processing has been completed, the VM unit 33a requests the kernel 34a to delete the thread. The application management unit 33b performs a process of starting an application, managing a thread added or deleted during execution of the application, and a process of terminating the application.

First, the process of starting the application will be described. Upon receiving the application start instruction from the instruction notification unit 36, the application management unit 33b causes the kernel 34a to generate a task and the first thread belonging to the task, and causes the VM unit 33a to execute the application with the generated first thread. By the VM
Resources required for the operation of the unit 33a are secured, and the application is started.

Next, management of a thread added or deleted during execution of an application will be described. The application management unit 33b holds a table indicating a correspondence relationship between an application, a task generated corresponding to the application, and a thread configuring the task, and updates the table each time a thread is added or deleted at the request of the application. By doing so, threads are managed in association with applications and tasks. FIG. 16 shows an example of the table. In FIG. 16- (1), two applications are being executed, a task with a task ID “201” is generated for an application with an application ID “1”, and a task with a task ID “201” is a thread ID.
It is composed of threads “1” and “2”, and the task ID “20” is assigned to the application ID “2”.
The task of task ID "202" is generated, and the task of task ID "202" is composed of threads with thread IDs "4", "5", and "6". While the application of “1” is being executed, a new thread (thread of thread ID “7”) is generated, and the thread ID “7” of the generated thread is added to the table, and FIG. 16- ( 3) is a thread while executing the application of application “2”.
This indicates that the thread with ID “5” has been deleted.

Finally, the process of terminating the application will be described. FIG. 17 is a flowchart illustrating a process performed by the application management unit 33b when the application ends. Upon receiving the application termination instruction from the instruction notification unit 36, the application management unit 33b notifies the kernel 34a of the ID of the task corresponding to the terminated application, and requests resource recovery (S801).
Next, the ID of the application to be terminated is notified to each class library unit included in the class library storage unit 33c (S802). (S803), the application is terminated. For example, in the example of FIG. 16- (3), when the application with the application ID “2” ends, the application management unit 33b stores the task I corresponding to the application ID “2” in the kernel 34a.
D “202” is notified and the task ID “20” is sent to the kernel 34a.
Requesting the collection of resources corresponding to "2", and then notifying the class library unit of the terminated application ID "2",
Finally, the task “202” generated by releasing the memory and the threads “4” and “6” included therein are terminated.

The class library storage unit 33c is composed of a plurality of class library units 33c1 to 33cn. Each class library unit controls a device which is a resource included in the hardware unit 35, performs resource provision processing, and manages a listener. And the process of calling the listener. Actually, the class library storage unit 33c is configured by a ROM, a hard disk, or the like. In each class library unit, a program described in a class group as a device control program is called by an application and executed. Device control is realized.

First, the resource providing process performed by each class library unit will be described. The class library part is
When called by an application executed by the VM unit 33a and requested to provide a device as a resource, the OS unit 3
And calls the library unit corresponding to the device stored in the library storage unit 34b of No. 4 and provides the requested resource.

Next, the listener management process performed by each class library unit will be described. The class library part is
The thread is called from an application executed by the VM unit 33a, registered as a listener, and generates a thread (hereinafter, referred to as a dedicated thread) for performing a process of calling the registered listener. The generation of the dedicated thread by the class library unit is executed by the thread executing the application. The class library section generates a dedicated thread for calling the listener as a thread belonging to the task executing the application.

Here, the listener is an event (a change in the state of the device due to a remote control input operation performed by the user or a disconnection of the modem from the other party).
Is a class or interface that waits for notification of the occurrence of an event. A method to be called when an event occurs is defined in the listener, and the event is processed by calling the method and executing the method. The registered listener is called when an event occurs. For example, when an event such as a remote control operation input by the user occurs, a method defined in the registered listener is called, and the event is processed by executing the called method. Also,
“Listener registration” means that the application requests the class library unit that monitors the event to “notify the application when an event occurs”. The above notification is executed by the class library unit calling a method defined for the listener when the listener is registered.

When a listener is registered, the class library unit calls the application management unit 33b,
Fetch the ID of the application that performs listener registration.
The application management unit 33b specifies the ID of the application by performing the following processing, and provides the specified ID to the class library unit. The application management unit 33b obtains an instance of the thread class of the thread that has made the call, and uses the hashcode function that is a method for extracting the hash code value held by the instance from the instance, and uses the hashcode function to call the ID (thread ID) of the instance that made the call. ), And the application ID and thread managed by the application management unit 33b.
The application ID corresponding to the thread ID is specified from the table showing the ID correspondence, and the specified ID is provided to the class library unit. Here, the extracted hash code value is an identification number (ID) assigned to each instance so that the VM unit 33a can efficiently manage the instances generated from the class. Each class library unit stores the application ID provided from the application management unit 33b, the ID of the generated dedicated thread, and the registered listener ID in a table in association with each other.

FIG. 18 is a flowchart showing a listener management process performed by the class library unit. When called from the application executed by the VM unit 33a for listener registration, the class library unit calls the application management unit 33b to acquire the ID of the application for which listener registration is to be performed (S501). Then, one of the set of the application ID, the dedicated thread, and the listener is extracted from the table indicating the correspondence between the application IDs (S502), and the application ID and the acquired application ID are compared (S503).

If the IDs match (S503: Y), a newly registered listener is added to the table in association with the ID (S504). If the IDs do not match (S503: N)
Retrieves the next set held in the table (S50
5, S502), and repeat the same processing. If the IDs do not match and the ID comparison ends (S505: Y), a dedicated thread corresponding to the newly registered listener is generated (S5).
06), a set of the acquired application ID, the generated dedicated thread, and the newly registered listener is added to the table and held (S507).

Thus, when the application held in the table registers the listener a plurality of times, the dedicated thread corresponding to the application can be specified from the table, and the plurality of listeners registered by the application can be identified by the specified one. It can be stored in a table corresponding to one dedicated thread. Therefore, a plurality of corresponding listeners can be called from one dedicated thread, so that it is not necessary to create a dedicated thread every time a listener is registered from an application, and the number of threads to be created can be reduced.

FIG. 19 shows an example of a table held by the class library unit. FIG. 19- (1) shows that the application with the application ID “1” has registered the listeners “L1” and “L4”, and the dedicated thread “thread10” corresponding to these listeners has been generated.
FIG. 19- (2) shows that the listener “L6” has been registered in the table of FIG. 19- (1) and the table has been updated. Specifically, when the listener “L6” is registered as a listener, the class library unit
3b to obtain the application ID of the application that registered the listener (here, ID “2”
Shall be obtained. ), It is determined whether or not it matches the application ID “1” held in the table of FIG. 19- (1). If it does not match, a new dedicated thread is created and the created dedicated thread “thread20” is created. And the application ID “2” and the listener “L6” are stored in a table in association with each other. In FIG. 19- (3), the application having the application ID “1” is terminated, and the dedicated thread “thread10” corresponding to the application ID “1” held in the table, the listener “L1” and the listener “L4” are displayed. Indicates that it was deleted from the table.

Next, processing performed from the occurrence of an event until the class library unit calls the registered listener from the dedicated thread will be described. This process is composed of two processes. The first process is a process of notifying that an event has occurred. This process is executed by a thread generated by the OS unit 34. FIG. 20 is a flowchart illustrating a process of notifying that an event has occurred. When the class library unit is notified of the event from the library unit included in the library storage unit 34b of the OS unit 34,
One of the sets is extracted from the table holding the set of the application ID, the dedicated thread, and the registered listener (S601), and the queue of the dedicated thread of the extracted set holds the call information necessary for calling the listener (S60).
2). Here, the queue transmits information between threads, and “holds one piece of information” and “takes out one piece of information”.
Two operations can be performed. The same process is performed for all the sets held in the table (S601 to S60
3).

The next process is a process for calling the registered listener. This process is executed by a dedicated thread generated by the class library unit. FIG.
9 is a flowchart showing a listener call process performed by the class library unit. The reclass library unit monitors whether or not the call information is held in the queue by executing the dedicated thread (S701),
If there is call information in the queue (S701: Y), it is extracted (S702), a listener corresponding to the dedicated thread is specified from the table (S703), and the listener is called (S704).
When there are a plurality of listeners corresponding to the dedicated thread, the listener calling process (S703, S704) is performed for all the corresponding listeners (S703 to S705). FIG. 22 is a diagram schematically illustrating an example of a procedure for calling a listener from a dedicated thread using a queue.

In FIG. 22, reference numerals 411 and 412 denote queues prepared for the dedicated thread "thread10" and the dedicated thread "thread20" in FIG. Also,
401 and 402 are dedicated threads “thread10”, respectively.
403 indicates the OS thread 34
Are threads generated by the OS unit 34 for notifying that an event has occurred from the library unit stored in the library storage unit 34b. And the broken lines 441 and 442 indicate that the held information is to be retrieved.

When the thread 403 notifies the class library that an event has occurred, the class library receives information (431, 43) necessary for calling the listener.
2) are held in the queues 411 and 412 (421 and 4).
22). The dedicated threads 401 and 402
It is monitored whether or not information is held in 1, 412. If the information is held, the information is retrieved and the corresponding listener is called. That is, the dedicated thread 401 sets the listener “L1” and the listener “L4” to the dedicated thread 402
Calls the listener "L6".

The OS section 34 is composed of a kernel 34a and a library storage section 34b, and operates the application indirectly by operating the Java middleware section 33. The kernel 34a manages resources provided to the application in units of tasks corresponding to the application. Specifically, the kernel 34a generates a task corresponding to the application and a first thread belonging to the task according to an instruction from the application management unit 33b, and secures resources necessary for the operation of the VM unit 33a in the first thread. . In addition, a thread requested by the application is generated, a resource requested by the application is provided by the generated thread, and a resource name of the provided resource is held in association with a task ID to which the thread belongs. When the notification of the task ID corresponding to the terminated application is received from the application management unit 33a, all the resources of the resource name held in association with the notified task ID are collected.

The library storage section 34b includes a plurality of library sections 34b1 to 34bn for controlling devices as resources.
Consists of Each library unit controls a device corresponding to the hardware unit 35 (for example, the library unit 34b1
Controls the device 35b1, and the library unit 34b2 controls the device 35b2. ). Actually library storage unit 3
Reference numeral 4b denotes a ROM or a hard disk, and in each library unit, a program describing a device control function group is called by a class of a class library and executed to implement device control.

The hardware unit 35 includes a CPU 35 a for operating the OS unit 34 and the Java middleware unit 33 and the device 3.
5b1 to 35bn. The CPU 35a executes the application program code by executing the thread generated by the kernel 34a. Device 3
5b1 to 35bn include a memory device, a display device, an input device (keyboard, remote controller, etc.), a file system, a network device, and the like. Each device operates according to control from an application performed through a class library and a library unit. I do.

The instruction notifying section 36 instructs the application management section 33b to start and end the application. Specifically, the application management unit 33b instructs the application management unit 33b to start the application, and receives an instruction to end the application from the outside.
Instruct b to terminate the application. The embodiments of the present invention have been described above, but it is needless to say that the present invention is not limited to the embodiments.

In the flowchart of FIG. 21, the class library executes a dedicated thread and constantly monitors whether or not the call information is held in the queue (S7).
01), the dedicated thread is put into a wait state in S701, and when the call information is held in the queue, the wait state of the dedicated thread is released, the dedicated thread is executed, and the processing in S702 to S705 is performed. It may be performed. Thereby, resources can be used efficiently.

The order of S801 and S802 in FIG. 17 may be reversed. Further, the number of threads generated for each application is not limited to the example in FIG. There may be more or less than this example. In the present embodiment, the resource management is performed by the kernel 34a, but may be performed by each library unit included in the library storage unit 34b. In this case, when the resource is supplied, the kernel 34a is inquired about the task for supplying the resource, and when the ID of the task is received from the kernel 34a, the notified task is received.
The ID and the resource name of the resource to be supplied are held as a set, and when there is an instruction to recover the resource of a specific task ID from the kernel 34a,
The resource name corresponding to the designated task ID is specified from the set holding the resource name, and the resource having the specified resource name is collected. Further, in the present embodiment, the VM unit 33a uses the first thread included in the task for executing the application in the VM unit 33a.
Although the resources required for a are reserved, the class library unit may generate a system-specific thread independent of the thread that executes the application, and the generated system-specific threads may reserve the necessary resources. The processing performed by the class library unit in this case is shown in FIG.
This will be described with reference to FIG. FIG. 23 is a flowchart illustrating a process in which the VM unit 33a acquires a thread dedicated to the system. The class library unit executes processing to be executed (for example, provides resources required by the application) with a thread that executes the application (S5401), and then generates a system-specific thread (S5402). A process to be executed (for example, a process for providing a necessary resource to the VM unit 33a) is executed (S5403), and when the process is completed, the result of the process is notified to the application (S540).
Four). The process of the thread that executes the application and the process of the thread dedicated to the system may be executed alternately and repeatedly an arbitrary number of times, or may be executed in parallel. Also, S5
The notification of 404 may be unnecessary.

As a result, the resources required by the VM unit 33a are secured by a thread dedicated to the system.
3a can execute the next application without reacquiring the resources necessary for itself even if the application ends. In addition, the class library section may secure necessary resources for itself by the above-mentioned system dedicated thread. For example, the system-dedicated thread may reserve a memory necessary to hold a table indicating the correspondence between the application ID, the thread instance, and the listener instance shown in FIG. 19 as an example.

In the present embodiment, the class library unit creates a dedicated thread. However, the thread is also created when a Component instance is provided from a Component class that provides a function for drawing on a screen during execution of an application. A calling thread for calling the paint method stored in the instance may be generated. Furthermore, the generation of the dedicated thread by the class library unit for the listener registration by the application may be completed when the application is started.

This eliminates the need for the class library unit to check for the presence of a dedicated thread every time a listener is registered, and can complete the listener registration process in a short time. (Embodiment 4) In the application execution apparatus according to the present embodiment, each library section collects resources provided to the application, and collects resources used by the application each time the application is terminated.

Specifically, the following processing is performed. When each library section is requested to provide a resource from an application via each class library section, the library section provides the requested resource, obtains the ID of the application that requested the resource from each class library section, and obtains the obtained application ID. And the resource name of the provided resource as a set, and retains the set in the table. Upon receiving the notification of the terminated application ID from the kernel 44a, the library unit specifies the resource name corresponding to the notified application ID from the held table, and collects all the resources with the specified resource name.

Hereinafter, embodiments of the present application execution apparatus will be described with reference to the drawings. FIG. 24 is a block diagram illustrating a configuration of the application execution device 40. The application execution device 40 includes an application input unit 11, an application storage unit 12, a Java middleware unit 43, an OS unit 44, a hardware unit 45, and an instruction notification unit 46.

The application input unit 11 and the application storage unit 12 are the same as those included in the execution device 10 according to the first embodiment, and the description is omitted. The Java middleware unit 43 includes a VM unit 43a, an application management unit 43b, and a class library storage unit 43c.
The application stored in the application storage unit 42 is executed.

The VM unit 43a stores the application storage unit 12
Load the application from, sequentially analyze the bytecode of the application, and execute the application. The application management unit 43b performs a process of starting the application executed by the VM unit 43b, a management of the running application, and a process of terminating the application.

First, the process of starting the application will be described. The application management unit 43b generates an instance of a class loader for each application, and loads all class files constituting the application using the instance of the class loader. Here, the class loader is a class that reads a class file used in a Java program into a memory.

Next, management of a running application will be described. The application management unit 43b holds a table in which an instance of a class loader that loads a class file configuring the started application and an ID assigned to the application are set.
Note that a different ID is assigned to each of the launched applications by the kernel 44a of the OS unit 44. FIG. 25 shows an example of a table in which an application ID corresponding to an instance of a class loader held by the application management unit 43b is set.

Next, the process of terminating the application will be described. The application management unit 43b controls the control unit 4
When the application termination instruction is received from 6, the kernel 44 a and the class library unit stored in the class library storage unit 43 c are notified of the application ID to be terminated. The application management unit 43b is further called from the class library unit that has provided resources to the application, and upon receiving a request for notification of the application ID of the application, performs the following processing to identify the application ID and notifies the class library. .

The application management unit 43b refers to the stack storing the call information of the class, acquires an instance of the class loader loaded with the application, and acquires the application ID corresponding to the instance of the class loader acquired from the held table. And notifies the class library unit of the specified application ID. Here, the stack is a memory area that is allocated as a work area of a method of the class. Each time a class is called by a method call, the work area of the called class is allocated in the stack. Classes that hold call information are stored in order. The call information stores information that specifies the caller of the method.

The application ID will be described below using a specific example.
The process of specifying the is described in detail. FIG. 26 is a schematic diagram showing a relationship between a class loader instance generated by the application management unit 43b and a stack. Here, the class loader instance 6301 calls the method of the class A constituting the application,
The called class A calls the method of another class B that constitutes the application, then class B calls another class C that constitutes the application, and finally the method of class D that class C stores in the class library section Will be described using an example in which a request for securing resources is made. In this case, the work area of the called class is allocated in the stack every time a call is made, and the call information is stored in the allocated work area. Reference numeral 6300 denotes a storage location of a class loader managed by the application management unit 43b. Here, two class loaders 6301 and 6302 are stored. 6
Reference numeral 310 denotes a stack, and 6311 to 6314 indicate call information stored in the classes A to D stored in the stack 6310. Application management unit 43b
When there is a request for specifying an application ID from the class library unit called by the class D, the stack 631
By sequentially referring to the call information 6314 to 6311 stored in “0”, an instance 6301 of the class loader loaded with the application is acquired. The application management unit 43b refers to the held table and specifies the application ID corresponding to the acquired class loader instance.

The class library storage unit 43c is composed of a plurality of class library units 43c1 to 43cn.
To control each device which is a resource included in. Actually, the class library storage unit 43c is configured by a ROM, a hard disk, or the like, and in each class library unit, a program described in a class group, which is a program for controlling each device, is called by an application and executed. Controls the respective devices.

When each class library unit is called from an application and requested to provide a device as a resource, the class library unit corresponding to the device included in the library storage unit 44b is called, and the requested resource is stored in the application application. To provide. Further, the class library section is an application of the application.
The ID is acquired from the application management unit 44b, and the acquired application ID is notified to the library unit.

The kernel 44a receives the notification of the application termination and the notification of the application ID of the terminated application from the application management unit 43b, notifies each library unit of the received application ID, and instructs the resource collection. Library storage unit 44b
Are a plurality of library units 44b1 to 44b4 for controlling devices.
4bn. Each library unit has a hardware unit 4
5 (for example, the library unit 44b1 controls the device 45b1, and the library unit 44b2 controls the device 45b1.
The device 45b2 is controlled. ).

Actually, the library storage section 44b is constituted by a ROM or a hard disk. In each library section, a program describing a function group for device control is called by a class of each class library section and executed. Control of a device as a resource is realized. Specifically, each library unit provides resources to the application in response to a call from the class library unit, receives a notification of the application ID of the application from the class library unit, receives the resource name of the provided resource, and The set of application IDs is stored in a table. When the notification of the application ID of the terminated application is received from the kernel 44a, the resource name corresponding to the notified application ID is specified from the held table, and the resource of the specified resource name is collected. FIG. 27 is an example of a table in which a resource name of a provided resource and an application ID are paired. In this example, the library unit provides resources (files) to two applications.
Is provided.

In this embodiment, a table in which the resource names of the resources provided by the respective library units and the application IDs are set is held.
a may hold a table. Also, in the present embodiment, the kernel 44a
Since D is generated, even when multiple middlewares are operated simultaneously, ID duplication caused by two middlewares generating IDs individually can be prevented, and the kernel 44a manages resources correctly. can do. (Embodiment 5) FIG. 28 is a block diagram showing a configuration of an application execution apparatus 100 according to an embodiment of the present invention. The application execution device 100 includes an application / class library storage unit 101, an application management unit 102, a VM (Virtual Machine) unit 10
3. It includes a memory heap management unit 104 and a memory 105. Here, the memory heap management unit 104 includes an object area acquisition unit 104a, a divided heap area acquisition unit 104b,
The system includes a divided heap area release unit 104c, a GC unit 104d, a lock unit 104e, and a memory heap area management table 104f.

The memory 105 has a plurality of divided heap areas 1
05a to 105n. Each divided heap area is provided corresponding to one application and is an area for holding an object related to the corresponding application. The reason why the divided heap area is provided for each application is that the target area of one garbage collection is not a whole memory heap area but a divided heap area unit. In addition, when the application ends, the memory heap area is released in divided heap area units.

The application / class library storage unit 101 stores a plurality of applications and an existing class library. Application management unit 102
Receives an instruction to start and end the application from outside, and instructs the VM unit 103 to start and end the application. The application management unit 102
Instructs the divided heap area release unit 104c to release the divided heap area in which the objects related to the application are arranged when the application ends.

Upon receiving the application start instruction from the application management unit 102, the VM unit 103 causes the memory heap management unit 104 to allocate a divided heap area for the application, and stores the application / class in the allocated divided heap area. The application is loaded from the library storage unit 101 and the loaded application is executed.

More specifically, the loading of an application can be divided into firstly loading a class loader object and secondly loading individual objects related to the application. First, loading of the class loader object will be described. The VM unit 103 receives an instruction to generate a class loader object for the application as the application activation instruction from the application management unit 102, and acquires an object area for the class loader object (hereinafter, referred to as a first acquisition instruction). ) To the object area acquisition unit 104
output to a. Here, the class loader object is an object for loading an object related to a corresponding application from the application / class library storage unit 101 into the divided heap area.

The VM unit 103 responds to the first acquisition instruction
Upon receiving the allocation of the divided heap area and the allocation of the object area from the object area obtaining unit 104a, the application / class library storage unit 101
And loads the class loader object into the object area and executes the class loader object.

Next, loading of individual objects related to the application will be described. VM unit 103
Executes this class loader object to store individual objects related to the corresponding application in the application / class library storage unit 1.
From 01, the data is loaded into the object area allocated by the object area obtaining unit 104a. That is,
The VM unit 103 sends an object area acquisition instruction (hereinafter, referred to as a second acquisition instruction) for an object related to the corresponding application to the object area acquisition unit 1.
When the object area is allocated from the object area acquisition unit 104a as a response to the second acquisition instruction, the object is loaded from the application / class library storage unit 101 to the object area and the object is executed. The second acquisition instruction is an instruction to acquire an object area for an object other than the class loader object,
If there is a request to generate another object from the running application, the object is output from the VM unit 103.

When receiving the first acquisition instruction from the VM unit 103, the object area acquisition unit 104a instructs the divided heap area acquisition unit 104b to acquire a divided heap area, and receives the allocation of the divided heap area. The class loader object area is acquired in the heap area, and the class loader object area is notified to the VM unit 103.

The memory heap management table 104f is composed of information on the divided heap area acquired by the divided heap area acquiring unit 104b (hereinafter, referred to as divided heap area information). As shown in FIG. 29, each divided heap area information includes an ID of the divided heap area, an ID of a class loader object loaded in the divided heap area, a start address of the divided heap area, a size of the entire divided heap area,
It is composed of the start address of a free area indicating an unused area in the divided heap area, and the size of the free area in the divided heap area. The new registration of the divided heap area information in the memory heap management table 104f is performed when the divided heap area acquiring unit 104b acquires the divided heap area in response to the instruction to acquire the divided heap area from the object area acquiring unit 104a. This is performed by the area acquisition unit 104b. The information about the start address of the free area in the divided heap area information and the size of the free area in the divided heap area is obtained by the object area obtaining unit 104a by the first or second obtaining instruction from the VM unit 103. It is updated every time. When the divided heap area release unit 104c releases the divided heap area allocated to the terminated application according to an instruction from the application management unit 102 after the application is terminated, the divided heap area information on the divided heap area is stored in the memory heap management. It is deleted from the table 104f.

The object area obtaining unit 104a
Receives the second acquisition instruction from the VM unit 103, identifies the class loader object loaded with the application requesting the second acquisition instruction, and manages the divided heap area corresponding to the identified class loader object in the memory heap area management. With reference to the table 104f, identification is performed (for example, when the identified class loader is CL2, the divided heap area b is identified), and an attempt is made to acquire an object area within the identified divided heap area. Object area acquisition unit 10
4a, when an object area can be obtained from the specified divided heap area, the object area is stored in the VM unit 103
To update the information of the divided heap area (the start address of the free area in the divided heap area, the size of the free area in the divided heap area) in the memory heap management table 104f.

On the other hand, the object area obtaining unit 104a
If the object area cannot be acquired from the divided heap area, the garbage collection unit instructs the GC unit 104d to perform garbage collection of the divided heap area, and attempts to acquire the object area again after the garbage collection ends. Upon receiving the divided heap region acquisition instruction from the object region acquiring unit 104a, the divided heap region acquiring unit 104b acquires the divided heap region from the memory heap region. The divided heap area acquisition unit 104b transmits the information of the acquired divided heap area 105a to the class loader object
A pair with D is registered in the heap memory area management table 104f.

Upon receiving an instruction to terminate the application from the application management unit 102, the divided heap area release unit 104c, in response to the instruction to release the divided heap area from the application management unit 102, loads the class loader object loaded with the terminated application. Heap area corresponding to the memory heap area management table 10
4f, the specified divided heap area is released, information on the released divided heap area (the ID of the released divided heap area, the ID of the class loader object corresponding to the divided heap area, the start address of the divided heap area) , The size of the entire divided heap area, the start address of the free area in the divided heap area, the size of the free area in the divided heap area, and the ID of the class loader object corresponding thereto) from the memory heap area management table 104f. I do.

The GC unit 104d performs garbage collection of the divided heap area according to an instruction from the object area obtaining unit 104a. The lock unit 104e stops the execution of the application using the divided heap area while the GC unit 104d performs the garbage collection of the divided heap area.

FIG. 30 is a flowchart showing an object area obtaining operation by the application execution apparatus 100 after receiving an object area obtaining instruction (first obtaining instruction or second obtaining instruction) from the VM unit 103. The object area acquisition unit 104a determines whether the object area acquisition instruction from the VM unit is a first (class loader object) acquisition instruction or a second (object other than the class loader) acquisition instruction (S1301).

In the case of the first acquisition instruction (S1301: Y), the object area acquiring unit 104a requests the divided heap area acquiring unit 104b to acquire a divided heap area corresponding to the class loader object, and the divided heap area acquiring unit 10
4b acquires a divided heap area from the memory 105 (S1302). The divided heap area acquisition unit 104b
As shown in the example of FIG.
The ID of the class loader object and the acquired information of the divided heap area are registered as a group in f (S1303). Next, the object area acquiring unit 104a acquires an object area of the class loader object in the divided heap area acquired by the divided heap area acquiring unit 104b (S130).
6, S1307), and updates information in the memory heap area management table 104f corresponding to the divided heap area (S130).
9).

In the case of the second acquisition instruction (S1301: N), the object area acquiring unit 104a acquires the class loader ID held by the object from the VM unit 103 (S130).
4) A divided heap area corresponding to the class loader ID is specified from the memory heap area management table 104f (S1305). Next, the object area acquiring unit 104a
An object area is acquired in the specified divided heap area (S1306). The object area obtaining unit 104a determines whether the object area has been successfully obtained (S130).
7).

When the object area has been successfully obtained (S1307: Y), the object area obtaining unit 104a updates the information of the memory heap area management table 104f corresponding to the divided heap area (S1309). If the acquisition of the object area has failed (S1307: N), the object area acquisition unit 104a instructs the GC unit 104d to perform garbage collection in the divided heap area that failed to acquire. The GC unit 104d performs garbage collection processing of the divided heap area according to the instruction (S1308). GC
While the unit 104d is performing the garbage collection process, the lock unit 104e stops the execution of the application using the divided heap area. After the garbage collection process, the object area acquisition unit 104a acquires an object area from the divided heap area again (S3
06), if the acquisition of the object area is successful (S1307:
Y), the information of the memory heap area management table 104f corresponding to the divided heap area is updated (S1309).

As described above, the application management apparatus 1
In 00, since the object area for arranging the generated objects is allocated as a divided heap area having a small memory size divided for each application, the load of one garbage collection process by the GC unit 104d can be reduced. When the VM unit 103 is executing a plurality of applications, the lock unit 104f stops only the application that uses the divided heap area during the garbage collection process of the divided heap area. The application using the divided heap area can be continuously executed.

FIG. 31 is a flowchart showing the operation of releasing the divided heap area by the application execution device 100 when the application is terminated. When the application ends, the application management unit 102 instructs the divided heap area release unit 104c to release the divided heap area corresponding to the class loader object loaded with the terminated application (S1401). The divided heap area release unit 104c specifies the divided heap area corresponding to the class loader object loaded with the application from the memory heap area management table 104f (S1402), and releases the divided heap area based on the information (S1403). ). Split heap area release unit 104c
Deletes the ID of the class loader object corresponding to the released divided heap area information from the memory heap area management table 104f (S1404). Accordingly, in the application execution device 100, each time the application is terminated, the corresponding divided heap area is collectively
Can be released in a short time.

In this embodiment, the divided heap area acquisition unit 104b allocates the divided heap area as the divided heap area for the system class loader object without being aware of the system class loader object. , The entire memory 105 is allocated as a memory area for the system class loader (system heap area 105-1), and the divided heap area acquisition unit 104b acquires a divided heap area corresponding to another class loader object in that area. (FIG. 32). In this case, the object area acquisition unit 104
“a” sets the object area of the system class loader object to the system heap area 105-1 at system startup.
And the ID of the system class loader object and the acquired area (for convenience of explanation, the divided heap area 105a0
Call. ) Information (divided heap area ID (a0), class loader ID (SCL), area start address (MA-0), total area size (MS-0), free area start address (FA-0), free area size (FS-0)) is registered as a set in the memory heap area management table 105f. Thereafter, as in the case of the present embodiment, each time the divided heap area acquisition unit 104b acquires the divided heap area from the system heap area 105-1 for the class loader object area, the divided heap area acquisition unit 104b returns to FIG. As shown, the ID of the class loader object and the information of the acquired divided heap area are added as a set to the memory heap area management table 104f, and the object area acquiring section is acquired by the divided heap area acquiring section 104b according to the flowchart of FIG. An object area in the divided heap area (S1
306) If the acquisition of the object area fails (S130)
7), the object area obtaining unit 104b
d instructs to perform garbage collection in the failed divided heap area, and the GC unit 104d performs garbage collection in the divided heap area according to the instruction (S1308). When the application ends, the application management unit 102 instructs the divided heap area release unit 104c to release the divided heap area corresponding to the class loader object loaded with the terminated application, and the divided heap area release unit 104c According to the instruction, the divided heap area is released according to the flowchart of FIG. Further, the GC unit 104d sets the entire system heap area 105-1 as a target of garbage collection and collects the divided heap areas released in units of the divided heap area, so that the system heap area 10
5-1 can be used efficiently.

Although the configuration of the application execution apparatus 100 of FIG. 28 according to the present embodiment is shown as a functional block diagram, actually, a CPU, a memory, hardware including an input / output device for performing input / output with the outside, and hardware and This is realized by executing software. This software is designed to manage the function of each block shown in FIG. When loading the software from a CD-ROM, a CD-ROM reading interface may be used. Memory is RAM, ROM, hard disk,
Consists of removable media such as CD drives, floppy disks, and memory cards.

In the present embodiment, the number of divided heap areas allocated to an application is not limited to one, but may be plural. For example, when the application itself has a class loader, a divided heap area is also allocated to the class loader. In the present embodiment, the size of the divided heap area acquired by the divided heap area acquisition unit 104b can be made variable by a program instruction to the divided heap area acquisition unit 104b.

[0105]

According to the present invention, there is provided an application execution apparatus including at least one library unit for providing resources to an application and a kernel unit, wherein the kernel unit determines which of the terminated applications when the application is terminated. It has a notifying means for notifying each library unit which has provided the resource whether there is, and each library unit has a collecting means for collecting the resources provided to the terminated application when notified from the notifying means. I do. Further, each means in the application execution device may be realized as a computer-readable recording medium storing a program for causing a computer to execute, or the collection means may determine a correspondence between an application and resources provided to the application. A table holding unit for holding a table indicated by the notifying unit, and a resource specifying unit for specifying, by the table holding unit, a resource provided to the application notified by the notifying unit. A providing means for providing a resource in response to a request from the client; and a requesting means for requesting the library unit to perform the notification when the providing means starts providing a new resource to the application and the application is terminated. Having and It may be.

According to this configuration, each time the application is terminated, unnecessary resources are collected by the library unit instead of the kernel unit. Therefore, it is not necessary to modify the kernel unit each time a new resource is added. The effect is obtained. Here, the notifying unit includes a plurality of notifying units that perform the notification for each application, and each of the library units further includes a providing unit that provides a resource in response to a request from the application; Requesting a notification unit corresponding to the application to provide the notification to the library unit when the application ends when the provision of a new resource is started, and the request unit includes: The library unit requests the notifying unit to perform the notification by calling a method of a resource recovery instance generated to receive the notification, and the requested notifying unit includes:
When the application ends, the notification may be made by calling a method of a resource collection instance.

According to this configuration, only the library unit that provides the resource to the terminated application is notified of the terminated application, so that unnecessary notification to the library unit that does not provide the resource is provided. The effect is obtained that the resource can be collected without performing the above. Here, the collecting unit specifies a table holding unit that holds a table indicating a correspondence relationship between an application and a resource provided to the application, and specifies the resource provided to the application notified by the notifying unit by the table holding unit. And a resource specifying unit, wherein the notifying unit notifies the library unit that provided the resource which of the plurality of terminated applications is to be provided when the plurality of applications are terminated simultaneously. The plurality of resources corresponding to the plurality of notified applications may be specified by the table holding unit, and the collection unit may collect the specified plurality of resources.

With this configuration, the library section can collectively collect resources provided to a plurality of terminated applications, so that more effective resource collection can be performed. Here, the notifying unit notifies each of the library units when the application is terminated or when the application is interrupted, and each of the library units further terminates or suspends the notified application. Depending on whether or not to collect the resources provided to the application,
Further, when it is determined that resources are to be collected, the resources provided to the notified application may be collected. Further, each unit in the application execution device may be realized as a computer-readable recording medium in which a program for causing a computer to be realized is recorded.

With this configuration, it is possible to determine whether resources should be collected depending on whether the application is suspended or terminated, and it is possible to collect only a specific part of resources. Further, the present invention is an application execution device including an OS unit for providing resources to an application and a Java middleware unit, wherein the Java middleware unit includes:
A first table holding unit for holding a table indicating a correspondence between an application and a task corresponding to the application and a thread constituting the task; Notifying means for notifying the task corresponding to the, the OS unit,
A task generating means for generating a task for executing the application for each application; a thread generating means for generating a plurality of application threads constituting the task; and executing the application thread by executing the application thread. A management unit that provides a resource requested by an application and holds a table indicating a correspondence between the provided resource and a task to which the thread belongs, and specifies a resource corresponding to the task notified from the notification unit by the management unit. And a collection unit for collecting resources provided to the application. Further, each unit in the application execution device may be realized as a computer-readable recording medium in which a program for causing a computer to be realized is recorded.

With this configuration, unnecessary resources are collected every time the application is terminated, so that there is an effect that resources for continuously executing the Java application can be secured. Here, the Java middleware unit further includes a resource securing thread generating unit configured to generate a resource securing thread for securing resources required for the Java middleware unit, separately from the application thread configuring the task. Resource securing means for securing resources necessary for the Java middleware section by executing the resource securing thread obtained, wherein the collecting means includes resources required for the Java middleware section secured by the resource securing means. Without collecting the resource, the resource corresponding to the task notified from the notifying unit may be specified by the managing unit, and the resource provided to the application may be collected.

According to this configuration, resources required for the Java middleware section are secured, and the resources are not collected even when the application ends, so that a new application can be executed in a shorter time. Further, the present invention is an application execution device that manages a memory heap area for an application that requires garbage collection, and a divided heap area acquisition unit that acquires a divided heap area from the memory heap area every time an application is started. Allocating means for allocating the divided heap area acquired by the divided heap area acquiring means to the started application, and memory releasing means for releasing the divided heap area allocated to the application every time the application is terminated. It may be provided with a feature. Also, a memory heap management method may be implemented in which each unit in the application execution device is a step, or a computer-readable recording medium that records a program for causing a computer to implement each unit in the application execution device may be implemented. .

With this configuration, every time the application is terminated, the divided heap area allocated to the terminated application is released, and garbage collection is not required inside the released divided heap area. Can be reduced. Here, the application execution apparatus further includes: an object area obtaining unit that obtains an object area in the divided heap area allocated to the application for an object related to the application; and a garbage collection for the divided heap area. Garbage collection means for performing
Further, a memory heap management method in which each unit in the application execution device is set as a step,
Each unit in the application execution device may be realized as a computer-readable recording medium storing a program for causing a computer to realize the means.

With this configuration, the load of one garbage collection can be reduced because garbage collection is performed on a divided heap area having a smaller memory size than the entire memory heap area. Here, the application execution device further stops execution of only applications that use the divided heap area while garbage collection of the target divided heap area is being performed by the garbage collection unit,
An application that uses another divided heap area may be provided with a lock unit that continuously executes the application.
Further, a memory heap management method in which each unit in the application execution device is set as a step,
Each unit in the application execution device may be realized as a computer-readable recording medium storing a program for causing a computer to realize the means.

With this configuration, even while the garbage collection is being performed, the execution of applications other than the application that uses the divided heap area that is the target of the process is continued, so that the user can terminate the process. You can continue working with other applications without having to wait.

[Brief description of the drawings] [Explanation of symbols]

FIG. 1 is a block diagram showing a configuration of an application execution device 10.

FIG. 2 shows an example of a C language program defining a callback function.

FIG. 3 shows an example of a C language program in which registration and call execution of a callback function are described.

FIG. 4 is a flowchart illustrating a resource providing process performed by each library unit.

FIG. 5 shows a table in which an application identifier and a resource name (file name) held by a library unit (hereinafter, referred to as a library unit F) that controls a file system are set.

FIG. 6 is a flowchart illustrating a resource collection process performed by each library unit.

FIG. 7 is a flowchart illustrating a resource collection process performed by each library unit when a plurality of applications are terminated at the same time.

FIG. 8 is a block diagram illustrating a configuration of an application execution device 20.

FIG. 9 shows an example of a Java program that defines an interface.

FIG. 10 shows an example of a class for generating an application information instance.

FIG. 11 shows an example of a resource collection class.

FIG. 12 shows an example of a resource collection instance generated by a resource collection class.

FIG. 13 is a flowchart illustrating a resource providing process performed by each library unit.

FIG. 14 is a flowchart illustrating a collection process performed by each library unit when an application information instance stores a method for knowing the state of an application and a method for deleting registration of a resource collection instance.

FIG. 15 is a block diagram illustrating a configuration of an application execution device 30.

FIG. 16 shows an example of a table showing a correspondence between applications, tasks generated corresponding to the applications, and threads constituting the tasks.

FIG. 17 is a flowchart illustrating a process performed by an application management unit 33b when an application ends.

FIG. 18 is a flowchart illustrating a listener management process performed by a class library unit.

FIG. 19 is an example of a table held by a class library unit.

FIG. 20 is a flowchart illustrating a process of notifying that an event has occurred.

FIG. 21 is a flowchart illustrating a listener call process performed by a class library unit.

FIG. 22 is a diagram schematically illustrating an example of a procedure for calling a listener from a dedicated thread using a queue.

FIG. 23 is a flowchart showing a process in which the VM unit 33a acquires a thread dedicated to the system.

FIG. 24 is a block diagram showing a configuration of an application execution device 40.

FIG. 25 shows an application corresponding to an instance of a class loader held by an application management unit 43b.
An example of a table in which IDs are set is shown.

FIG. 26 is a schematic diagram illustrating a relationship between a class loader instance generated by an application management unit 43b and a stack.

FIG. 27 shows a resource name and an application ID of a provided resource.
Is shown as an example of a table in which.

FIG. 28 is a block diagram showing a configuration of an application execution device 100.

FIG. 29 is a diagram showing states of a memory heap area management table 104f and a memory 105.

FIG. 30 is a flowchart showing an operation of acquiring an object area by the application execution apparatus 100 after receiving an instruction to acquire an object area from the VM unit 103.

FIG. 31 is a flowchart showing an operation of releasing the divided heap area by the application execution device 100 when the application is terminated.

FIG. 32 is a diagram showing a state in which a system heap area 105-1 is registered in a memory heap area management table 104f.

[Explanation of symbols]

 Reference Signs List 1 memory heap management unit 2 heap area acquisition unit 3 GC (garbage collection) unit 10 application execution unit 11 application input unit 12 application storage unit 13 kernel unit 13a sequential execution unit 13b resource collection notification unit 13c identifier providing unit 14 library storage unit 14a To n library unit 15 device unit 15a to n device 20 application execution unit 23 OS unit 23a virtual machine unit 23b application management unit 23c to e application information instance 24 library storage unit 24a to n library unit 30 application execution unit 33 Java middleware unit 33a VM unit 33b Application management unit 33c Class library storage unit 33c1-c2 Class library unit 34 OS unit 34a Kernel 34b Library storage unit 34 b1 to b2 library unit 35 hardware unit 35a CPU 35b1 to b2 device 40 application execution unit 43 Java middleware unit 43a VM unit 43b application management unit 43c class library storage unit 43c1 to c2 class library unit 44 OS unit 44a kernel 44b library storage unit 44b1 to b2 library unit 45 hardware unit 45a CPU 45b1 to b2 device 100 application execution unit 101 application / class library storage unit 102 application management unit 103 VM unit 104 memory heap management unit 104a object area acquisition unit 104b divided heap area acquisition unit 104c Divided heap area release unit 104d GC unit 104e Lock unit 104f Memory heap area management table 105 Memory 105a to 105n Divided heap area

 ──────────────────────────────────────────────────の Continuing on the front page (72) Inventor Kenji Hiramoto 1006 Kazuma Kadoma, Osaka Prefecture Matsushita Electric Industrial Co., Ltd. (72) Inventor Shigenori Doi 1006 Kadoma, Kazuma, Osaka Prefecture Matsushita Electric Industrial Co., Ltd.F-term (reference) 5B060 AA10 5B098 GD03 GD07 GD14 GD22

Claims (50)

[Claims] 1. An application execution apparatus comprising at least one library unit and a kernel unit for providing resources to an application, wherein the kernel unit, when the application is terminated, determines which of the terminated applications is a resource. An application execution device, comprising: a notifying unit for notifying each library unit that provided the application, and each library unit having a collection unit for collecting resources provided to the terminated application when notified from the notifying unit. . 2. The information processing apparatus according to claim 1, wherein the collection unit includes: a table holding unit that holds a table indicating a correspondence relationship between the application and the resource provided to the application; and a table holding unit that stores the resource provided to the application notified by the notification unit. 2. The application execution device according to claim 1, further comprising a resource specifying unit for specifying. 3. The library unit further includes: a providing unit that provides a resource in response to a request from an application; and a notification as to which application provided the resource from the kernel unit. A registration unit for registering the provided application and the provided resource in association with each other as a set, and a set indicating a correspondence between the collected resource and the corresponding application when the registered resource is collected by the collection unit. 3. The application execution device according to claim 2, further comprising: a deletion unit configured to delete the application from the table. 4. Each of the library units further includes: a providing unit that provides a resource in response to a request from an application; and when the providing unit starts providing a new resource to the application, the library unit terminates the application. 2. The application execution device according to claim 1, further comprising request means for requesting the notification. 5. The notifying unit requests the kernel unit to call a callback function, and the kernel unit calls and executes the requested callback function when the application is terminated, whereby the notifying unit notifies the notification unit. 5. The application execution device according to claim 4, wherein the notification is performed as: 6. The notifying unit includes a plurality of notifying units that make the notification for each application, wherein each of the library units further provides a resource in response to a request from the application; Request means for requesting a notification unit corresponding to the application to make a notification to the library unit when the application ends when the application starts providing new resources to the application. The application execution device according to 1. 7. The requesting means requests the notifying unit to perform the notification by calling a method of a resource recovery instance generated by the book library unit to receive the notification, and the requested notifying unit is 7. The application execution device according to claim 6, wherein when the application is terminated, the notification is performed by calling a method of a resource recovery instance. 8. The collection unit includes: a table holding unit that holds a table indicating a correspondence between an application and a resource provided to the application; and a table holding unit that stores the resource provided to the application notified by the notification unit. A resource specifying unit for specifying, when the plurality of applications are simultaneously terminated, the notifying unit notifies the library unit that provided the resource which of the plurality of terminated applications is, 2. The application execution method according to claim 1, wherein the means specifies a plurality of resources corresponding to the notified applications by the table holding means, and the collection means collects the specified resources. apparatus. 9. The application execution device according to claim 1, wherein each of the library units provides any one of a tuner, an MPEG decoder, a remote controller, a file system, a memory, and a modem as the resource to the application. 10. The collection unit includes: a table holding unit that holds a table indicating a correspondence between an application and a resource provided to the application; and a table holding unit that stores the resource provided to the application notified by the notification unit. 10. The application execution device according to claim 9, further comprising a resource specifying unit for specifying. 11. Each of the library units further includes: a providing unit that provides a resource in response to a request from an application; and a notification as to which application provided the resource from the kernel unit. Registration means for registering the application that provided the resource and the provided resource in association with each other; and deleting means for deleting the application corresponding to the recovered resource from the table when the registered resource is recovered by the recovery means. The application execution device according to claim 10, further comprising: 12. Each of the library units further includes: a providing unit that provides a resource in response to a request from an application; and when the providing unit starts providing a new resource to the application, the library unit terminates the application. 10. The application execution apparatus according to claim 9, further comprising request means for requesting the notification. 13. The notifying unit requests the kernel unit to call a callback function. When the application is terminated, the kernel unit calls and executes the requested callback function to execute the notification unit. 13. The application execution apparatus according to claim 12, wherein the notification is performed as: 14. The notifying unit includes a plurality of notifying units that perform the notification for each application, each of the library units further includes a providing unit that provides a resource in response to a request from the application, and the providing unit includes: 10. A requesting means for requesting a notifying unit corresponding to the application to perform the notification when the application ends in the library unit when the provision of a new resource is started. Application execution device. 15. The requesting unit requests the notifying unit to perform the notification by calling a method of a resource recovery instance generated by the book library unit to receive the notification, and the requested notifying unit is 15. The application execution apparatus according to claim 14, wherein when the application is terminated, the notification is performed by calling a method of a resource recovery instance. 16. The collection means, wherein: a table holding means for holding a table indicating a correspondence between an application and resources provided to the application; and a resource provided to the application notified by the notifying means, by the table holding means. A resource specifying unit for specifying, when the plurality of applications are simultaneously terminated, the notifying unit notifies the library unit that provided the resource which of the plurality of terminated applications is, The application execution according to claim 9, wherein the means specifies a plurality of resources corresponding to the notified applications by the table holding means, and the collection means collects the specified resources. apparatus. 17. The notifying means further notifies each of the library units when the application is terminated or when the application is interrupted, and each of the library units further determines whether or not the notified application is terminated. A determining unit that determines whether to recover the resources provided to the application according to whether the application has been interrupted, and the recovery unit provides the notified application when it is determined that the resources are to be further recovered. 2. The application execution device according to claim 1, wherein the resource is collected. 18. The notifying unit includes a plurality of notifying units that perform the notification for each application, wherein each of the library units further includes: a providing unit that provides a resource in response to a request from the application; When the provision of new resources to the application is started, the library unit requests the notification unit corresponding to the application to notify the library unit when the application is terminated or when the application is interrupted. 18. The application execution device according to claim 17, further comprising request means. 19. The requesting unit requests the notifying unit to perform the notification by calling a method of a resource recovery instance generated by the book library unit to receive the notification, and the requested notifying unit is The notification is performed by calling the method of the resource recovery instance either when the application is terminated or when the application is interrupted. When the determination unit receives the notification, the application terminates. 19. The application execution apparatus according to claim 18, wherein information about whether or not the application has been interrupted is obtained, and whether to collect resources provided to the application is determined according to the information. 20. An OS for providing resources to an application
An application execution device comprising a Java middleware unit and a Java middleware unit, the Java middleware unit comprising: a first table holding unit that holds a table indicating a correspondence relationship between an application, a task corresponding to the application, and a thread configuring the task; Notifying means for receiving a termination instruction and notifying which task corresponds to the application to be terminated with reference to the first table holding means, wherein the OS unit executes the application for each application A task generating means for generating a task to be executed; a thread generating means for generating a plurality of application threads constituting the task; and executing the application thread to execute an application program code. Management means for providing a resource to be provided, and holding a table indicating a correspondence relationship between the provided resource and the task to which the thread belongs; and specifying, from the management means, a resource corresponding to the task notified from the notification means from the management means. An application execution device comprising: a collection unit configured to collect the provided resources. 21. A requesting means for requesting a running application to be notified of a change in the state of a device, the Java middleware unit further comprising: 21. The application execution apparatus according to claim 20, further comprising: a status change notification unit configured to notify that the change has occurred. 22. The requesting unit requests the state change notifying unit to call a listener waiting for a notification that the change has occurred, and the state change notifying unit detects the change when detecting the change. 22. The application execution device according to claim 21, wherein the notification is made by calling a listener. 23. The state change notifying means generates a dedicated thread for executing the call of the listener, and calls the listener by executing the dedicated thread. The Java middleware unit further includes: A second table holding unit for holding a table indicating a correspondence relationship between the dedicated thread and the application, and each time the request unit requests the state change notification unit to call the listener, the table is referred to, A table updating means for determining whether or not an application corresponding to the listener is held in the table, and if held, adding the listener to the table in association with the application; and Notifying means is provided by the table updating means. The dedicated thread is not newly generated when it is determined that the dedicated thread is held, and the dedicated thread is newly generated when it is determined that the dedicated thread is not held. 23. The application execution device according to 22. 24. The dedicated thread monitors whether information indicating that the change has occurred is held in a queue for transmitting information between threads, and responds to the case where the information is held. The application execution device according to claim 23, wherein the listener is called. 25. The dedicated thread is in a wait state before information indicating the occurrence of the change is held in a queue for transmitting information between threads, and is in an execution state when information is held in the queue. 24. The application execution device according to claim 23, wherein the process proceeds to step (b), and the corresponding listener is called. 26. The Java middleware unit further comprises: a resource securing thread generating unit configured to generate a resource securing thread for securing resources required for the Java middleware unit, separately from the application thread configuring the task. By executing the generated resource securing thread,
A resource securing unit for securing resources required for the Java middleware unit, wherein the collecting unit notifies the Java middleware unit from the notifying unit without collecting the resources required for the Java middleware unit secured by the resource securing unit. 21. The application execution apparatus according to claim 20, wherein a resource corresponding to the task specified is specified by the management unit, and the resource provided to the application is collected. 27. An OS for providing resources to an application
An application execution device comprising a unit and a middleware unit, wherein the middleware unit notifies which application has requested the provision of resources in response to a request from the OS unit, and terminates when the application ends. A notification unit for notifying an application, the OS unit includes a request unit for requesting a notification of an application which has requested the provision of the resource, and a correspondence between the notified application and the resource A resource management table means for holding a table indicating the relationship; and a notification means for notifying which application has been terminated, a resource corresponding to the terminated application is specified by the resource management table means, and the specified resource Having resource recovery means for recovering resources Execution device. 28. The notifying unit includes: a loader specifying unit that specifies a class loader that has loaded an application requesting provision of resources; and a table unit that holds a table indicating a correspondence between the class loader that has loaded the application and the application. 28. The application execution device according to claim 27, further comprising: an application specifying unit that specifies an application corresponding to the class loader specified by the loader specifying unit from the table. 29. The method according to claim 29, wherein the loader specifying unit specifies a class loader loaded with the application that has requested the provision of the resource by referring to a stack storing caller information of a class configuring the application. 29. The application execution device according to claim 28. 30. The OS unit further comprises an assigning means for assigning an ID for specifying an application for each application, wherein the notifying means is assigned by the assigning means.
3. The method according to claim 2, wherein by notifying the ID, the application which provided the resource is notified, and the application which has been terminated is notified.
9. The application execution device according to item 9. 31. The OS unit further comprises an assigning means for assigning an ID for specifying an application for each application, wherein the notifying means is assigned by the assigning means.
3. The method according to claim 2, wherein by notifying the ID, the application which provided the resource is notified, and the application which has been terminated is notified.
9. The application execution device according to 8. 32. The OS unit further comprises an assigning means for assigning an ID for specifying an application for each application, wherein the notifying means is assigned by the assigning means.
3. The method according to claim 2, wherein by notifying the ID, the application which provided the resource is notified, and the application which has been terminated is notified.
8. The application execution device according to 7. 33. A computer-readable recording medium recording a program used for an application execution device including a plurality of library units and a kernel unit for providing resources to an application, wherein the program is a computer-readable recording medium. A recording medium which causes a computer to realize the means according to any one of the preceding claims. 34. An OS for providing resources to an application
21. A computer-readable recording medium recording a program used in an application execution device including a unit and a Java middleware unit, wherein the program causes a computer to realize the means according to claim 20. . 35. An OS for providing resources to an application
28. A computer-readable recording medium recording a program used for an application execution device including a unit and a middleware unit, wherein the program causes a computer to realize the unit according to claim 27. 36. An application execution device that manages a memory heap area for an application that requires garbage collection, wherein each time an application is started, a divided heap area acquiring unit acquires a divided heap area from the memory heap area. Allocating means for allocating the divided heap area acquired by the divided heap area acquiring means to the started application; and memory releasing means for releasing the divided heap area allocated to the application every time the application is terminated. An application execution device, comprising: 37. The application execution device, further comprising: an object area acquiring means for acquiring an object area in an object related to the application within a divided heap area allocated to the application; The application execution apparatus according to claim 36, further comprising garbage collection means for performing garbage collection. 38. While the garbage collection unit is performing garbage collection of the target divided heap area, the application execution apparatus stops execution of only an application that uses the divided heap area, and executes another division. 38. The application execution apparatus according to claim 37, wherein the application using the heap area includes a lock unit that continuously executes the application. 39. The application execution device further comprises table means for holding a table indicating a correspondence between a running application and a divided heap area, and the memory releasing means stores a divided heap area corresponding to the terminated application. 37. The application execution device according to claim 36, wherein the application execution device is specified and released from the table. 40. The application execution apparatus further comprises table means for holding a table indicating a correspondence between the running application and the divided heap area, and the allocating means further comprises: 37. The application execution device according to claim 36, wherein a new correspondence between the application and the divided area is added to the table. 41. An application execution apparatus for managing a memory heap area for an application requiring garbage collection, comprising: a system heap area allocating means for allocating an entire memory heap area as a system heap area; Means for obtaining an object area in a heap area, means for obtaining a divided heap area from a system heap area each time an application is started, and means for obtaining a divided heap area for a started application. An application execution apparatus, comprising: an allocating means for allocating; and a memory releasing means for releasing a divided heap area allocated to the application when the application ends. 42. The application execution device according to claim 41, wherein the application execution device further comprises a garbage collection unit that performs garbage collection in units of a divided heap region for a system heap region. 43. A memory heap management method for managing a memory heap area for an application that requires garbage collection, wherein each time the application is started, a divided heap area is acquired from the memory heap area. An allocation step of allocating the divided heap area acquired by the divided heap area acquisition step to the started application; and a memory releasing step of releasing the divided heap area allocated to the application every time the application ends. A memory heap management method, comprising: 44. The memory heap management method, further comprising: for an object related to an application, an object area acquiring step of acquiring an object area within a divided heap area allocated to the application; 44. The memory heap management method according to claim 43, further comprising a garbage collection step of performing garbage collection for each of the divided heap areas when the acquisition of the area has failed. 45. The memory heap management method further comprises:
While the garbage collection of the target divided heap area is being performed by the garbage collection step, only the application using the divided heap area stops executing, and the application using the other divided heap area is continuously executed. The memory heap management method according to claim 44, further comprising a lock step. 46. The memory heap management method further comprises:
The method further includes a table holding step of holding a table indicating a correspondence relationship between a running application and a divided heap area, wherein the memory releasing step specifies and releases a divided heap area corresponding to the terminated application from the table. The memory heap management method according to claim 43, wherein 47. The memory heap management method further comprises:
A table holding step of holding a table indicating a correspondence relationship between the running application and the divided heap area, wherein the assigning step further includes, every time the application is started, a new correspondence between the application and the divided area. The memory heap management method according to claim 43, wherein the memory heap is added to the table. 48. A memory heap management method for managing a memory heap area for an application requiring garbage collection, comprising: a system heap area allocating step of allocating the entire memory heap area as a system heap area; An object area acquiring step for acquiring in the system heap area, a divided heap area acquiring step for acquiring a divided heap area from the system heap area every time the application is started, and a divided heap area acquired for the started application. A memory heap management method, comprising: an allocation step of allocating the application; and a memory release step of releasing a divided heap area allocated to the application when the application ends. 49. The memory heap management method further comprises:
49. The memory according to claim 48, further comprising a garbage collection step of performing garbage collection in units of the divided heap area for the inside of the system heap area when the divided heap area acquisition step fails to acquire the divided heap area. Heap management method. 50. A computer-readable recording medium recording a program used for an apparatus for executing an application that requires garbage collection, wherein the program is a program according to any one of claims 43 to 49. Recording medium characterized by causing a computer to execute the following.