JP5684633B2 - Memory management device, memory management method, and memory management program - Google Patents

Description

  The present invention relates to a technique for managing a memory used by a bundle based on an OSGi standard specification.

[About OSGi]
OSGi is a software modularization technology. A software module based on the OSGi standard specification is called a bundle.

As a system architecture, as shown in FIG. 18, a Java (registered trademark) VM (Java Virtual Machine) operates as one process on an OS (Operating System) of an operating terminal, and bundles are created on the Java VM. OSGiFW (OSGi Framework), which is an execution environment, operates. A plurality of bundles can be operated on the OSGiFW. OSGiFW and bundles are Java programs.

  To run a Java program on JavaVM, first, source code written in the Java language is compiled into a class file that is a binary file that can be interpreted by JavaVM. JavaVM interprets the class file and executes the program.

  A bundle is a set of files necessary for executing a program such as a class file or an image file. The OSGi specification defines a mechanism in which a plurality of bundles cooperate, that is, a mechanism in which another bundle can call a class file provided by a bundle.

  One of them is cooperation by OSGi service. Specifically, as shown in FIG. 19, the bundle A provides an implementation class of the service S defined by the Java interface, and registers the generated object as an OSGi service in the OSGiFW service registry.

  The bundle B can acquire the OSGi service registered in the service registry and call the service S method of the object.

  In addition, there is cooperation by Import / Export of packages.

[Providing and using functions]
In many OSGi services, as shown in FIG. 20, the bundle C in which the OSGi service is registered provides a function for the bundle D through the service S.

  For example, in the HTTP Service defined by the OSGi specification, the bundle C provides an HTTP Service implementation class and performs service registration, thereby providing a Java Servlet registration function to an HTTP server to other bundles. The bundle D obtains and calls the HttpService to use the HttpService function of the class provided by the bundle C.

  On the other hand, in the case of a callback type call, the provision and use of functions are reversed. As an example, as shown in FIG. 21, there is an event notification when there is a bundle E that manages certain information and a bundle F that is desired to be notified when the information is changed.

  In this case, the bundle F provides the OSGi service implementation class that becomes the event listener L, registers the service in the service registry, and when the bundle E is to notify the event, obtains the registered OSGi service and calls it. Back.

  That is, a function called event notification is provided by a bundle E that performs a call, and a bundle F that provides a class uses the function.

  The relationship between the provision and use of such functions also exists in bundles and OSGiFW, bundles and JavaVM, etc., in addition to cooperation between bundles.

[About JavaVM]
In the conventional technology, the memory required for the bundle, OSGiFW, and JavaVM itself to operate is secured by the JavaVM from one heap memory (heap area) allocated from the OS. Specifically, for example, a memory used (secured / consumed) by a bundle called by a certain thread is secured from one heap area. Hereinafter, it may be described by the expression of memory allocation.

  Further, in a thread operating on JavaVM, memory allocation always occurs in the top stack (TOPSTACK) of each thread called last, as shown in FIG. The bundle of the system, OSGiFW, and JavaVM, share one heap memory.

  If the memory amount necessary for memory allocation cannot be secured, GC (Garbage Collection) is performed, and the memory area of the object that is not referenced at that time is released. If the required amount of memory cannot be secured even after GC, an OOM (Out Of Memory) error occurs. If an OOM error is caught and handled, the entity may fail to operate if it is not appropriate for each entity.

  In the present invention, “the case where the necessary amount of memory cannot be secured” refers to the case where the necessary amount of memory cannot be secured even when GC is performed.

  As shown in FIG. 23, the JavaVM stack structure is generally (1) triggered by a call from the caller stack, and (2) memory allocation is performed in the processing in the class providing stack. In the present invention, a class of processing performed in the stack is defined as an implementation class, and a class loader of the class is defined as an implementation class loader.

"The Java Virtual Machine Specification, 3.5.3 Heap, 4.1 The ClassFile Structure", [Online], searched on March 18, 2011, <URL: http://java.sun.com/docs/books/jvms/ second_edition / html / VMSpecTOC.doc.html> “OSGi Alliance”, [Online], search on April 1, 2011, <URL: http://www.osgi.org/Specifications/HomePage>

  In the conventional technology, the bundle, OSGiFW, and JavaVM share the heap area. If an OOM error occurs at a certain entity and the memory is not released, other entities can also secure new memory after that point. As a result, all the systems may stop.

  A particular problem arises when a plurality of business operators share a single system and provide services simultaneously using conventional technology.

  For example, a platform provider (hereinafter referred to as a PF provider) provides a platform system part such as JavaVM or OSGiFW, and a service provider (hereinafter referred to as an SP provider) provides a bundle developed by itself. Assume that a service is provided by operating on a platform system provided by a PF company.

  At this time, if a bundle created by a certain SP provider consumes more memory than expected due to a bug or the like, it will not be able to operate until another Entity that should have been able to operate normally without the bug. Other entities are JavaVM, OSGiFW, other bundles, and the like.

  In other words, all the entities (systems provided by PF providers and SP provider bundles) that operate on JavaVM that should be operating normally become inoperable due to a bug in one SP provider bundle. It happens.

  As described above, in OSGi, components such as a bundle and OSGiFW are linked. The definition of whether the memory consumed when linking is counted as “caller” or “provided by class” is not defined in the specifications of OSGi or Java (Non-patent Document 1, Non-patent Document 1) Patent Document 2). Since the definition is not fixed, the memory consumption of the bundle cannot be measured.

  The present invention has been made in view of the above-mentioned problems, and the object of the present invention is to limit the memory consumption in an arbitrary unit.

The memory management device according to claim 1 is a memory management device that manages a memory used by a bundle based on an OSGi standard specification, and stores information on a memory amount permitted to be used by a bundle group having one or more bundles from a storage unit. A memory management bundle that performs a request to secure a heap area that is the same size as the amount of memory that is read, and secures the heap area from the heap area of its own device, and the memory area used by the bundle group is assigned to the heap area. A plurality of bundle groups, the plurality of bundle groups have a relationship of being called and called in a thread, and the memory management bundle is a bundle that is called first The request is made only for the group, and the request is made for bundle groups other than the bundle group. The Java virtual machine, the memory area in which all the bundles group utilized, and allocates the heap area secured against the bundle group was first called.

  According to the present invention, since the memory area used by the bundle group is allocated to the heap area secured with the same size as the amount of memory permitted to be used by the bundle group, the memory consumption amount consumed by the bundle group is arbitrary. Can be limited in units.

The memory management device according to claim 2 is a memory management device that manages a memory used by a bundle based on the OSGi standard specification, and stores information on a memory amount permitted to be used by a bundle group having one or more bundles from a storage unit. A memory management bundle that performs a request to secure a heap area that is the same size as the amount of memory that is read, and secures the heap area from the heap area of its own device, and the memory area used by the bundle group is assigned to the heap area. anda Java virtual machine to be allocated to, a plurality of the bundles group, the plurality of bundles groups, in function providing bundle groups and functional utilization bundle group having a relationship of providing and use of functions of the bundle at one thread there are, the memory management bundle, performs the request only for the function use bundle group, For serial function providing bundle group without the request, the Java virtual machine, and wherein assigning a memory area in which the function providing bundle group utilized, the heap area allocated to the function use bundle group To do.

The memory management method according to claim 3 is a memory management method for managing a memory used by a bundle based on an OSGi standard specification, wherein information on an amount of memory permitted to be used by a computer for a bundle group having one or more bundles is obtained. A first step of reading from the storage means and making a request to secure a heap area having the same size as the amount of memory, securing the heap area from the heap area of its own machine, and a memory area used by the bundle group, A second step of allocating to the heap area, comprising a plurality of bundle groups, wherein the plurality of bundle groups have a relationship of being called and called in a certain thread, and the first step is to call the only performed bundle group performs the request, the line the request for bundle group other than the bundle group Not, the second step is a memory area that all of the bundle group utilized, and allocates the heap area secured against the bundle group was first called.

  According to the present invention, since the memory area used by all bundle groups is allocated to the heap area reserved for the bundle group that is first called, the memory consumption can be counted in units of threads. Can limit memory consumption.

5. The memory management method according to claim 4, wherein the memory management method manages the memory used by the bundle based on the OSGi standard specification, and information on the amount of memory permitted to be used by the computer for the bundle group having one or more bundles. A first step of reading from the storage means and making a request to secure a heap area having the same size as the amount of memory, securing the heap area from the heap area of its own machine, and a memory area used by the bundle group, and a second step of assigning to the heap area, and a plurality of the bundles group, the plurality of bundles groups function providing bundle group and functional use with the relationship provision and use of functions of the bundle at one thread a bundle group, the first step may perform the request only for the function use bundle group Without the request for the function providing bundle group, the second step includes a feature to allocate a memory area in which the function providing bundle group utilized, the heap area allocated to the function use bundle group To do.

  According to the present invention, since the memory area used by the function providing bundle group is allocated to the heap area reserved for the function using bundle group, the memory consumption can be counted in units of function using bundle groups. Memory consumption can be limited.

The memory management method according to claim 5 is the memory management method according to claim 4 , wherein the function providing bundle group is a bundle group generated by a platform provider that provides a function, and the function using bundle group is: A bundle group generated by a service provider that uses a function, or the function providing bundle group is a bundle group generated by a service provider that provides a function, and the function using bundle group It is a bundle group generated by a service provider to be used.

A memory management method according to a sixth aspect further includes a step of calculating a memory consumption amount used in the heap area in the memory management method according to any one of the third to fifth aspects.

According to the present invention, since the memory consumption used in the heap area described in any one of claims 3 to 5 is calculated, the memory consumption can be measured for each restriction target.

According to a seventh aspect of the present invention, there is provided a memory management program that causes a computer to execute the steps according to any of the third to sixth aspects.

  According to the present invention, the memory consumption can be limited in an arbitrary unit.

It is a figure which shows the structure of a memory management apparatus. It is a figure explaining the structure of a memory management apparatus. It is a figure which shows the structure of the memory management system which has an external server. It is a figure which shows the stack of the quadrant a. It is a figure which shows the stack of the quadrant b. It is a figure which shows the stack of the quadrant c. It is a figure which shows the stack of the quadrant d. It is a table | surface which shows the relationship of the stack of quadrant ad. It is a figure which shows the specific example of the stack referred when each heap selection algorithm is demonstrated. It is a figure which shows the specific example of the stack referred when each heap selection algorithm is demonstrated. It is a flowchart which shows operation | movement of a 1st heap selection algorithm. It is a flowchart which shows operation | movement of a 2nd heap selection algorithm. It is a flowchart which shows operation | movement of a 3rd heap selection algorithm. It is a table | surface which shows the relationship between a caller and a class provision stack. It is a flowchart which shows operation | movement of a 4th heap selection algorithm. It is a table | surface which shows the relationship between a caller and a class provision stack. It is a figure which shows an example of the calling function of PF set. It is a flowchart which shows operation | movement of the 5th heap selection algorithm. It is a figure which shows the system architecture of OSGi. It is a figure which shows the cooperation between bundles by an OSGi service. It is a figure which shows provision and utilization of a bundle function. It is a figure which shows utilization and provision of a bundle function. It is a figure explaining memory allocation. It is a figure explaining the stack structure of JavaVM.

  Hereinafter, an embodiment for carrying out the present invention will be described with reference to the drawings. However, the present invention can be implemented in many different modes and should not be construed as being limited to the description of the present embodiment.

[Configuration of memory management device]
First, the configuration of the memory management device 1 will be described.

  FIG. 1 is a diagram showing a configuration of a memory management device according to the present embodiment. The memory management device 1 is a device that manages memory used (reserved / consumed) by a bundle based on the OSGi standard specifications, and includes a Java VM 10 that runs on the OS, and an OSGiFW 11 that provides a bundle execution environment on the Java VM. , The OSGiFW mainly includes a plurality of owner bundles 12 and a plurality of SP bundle sets 13 that operate as Java programs.

  As shown in FIG. 2, a bundle created by the PF provider is referred to as an owner bundle 12, and a bundle created by the SP provider for providing a service is referred to as an SP bundle 131.

  Further, a bundle group composed of one or more bundles is used as a bundle set, an SP bundle group created by an SP provider is an SP bundle set 13, and a Java VM 10, OSGiFW 11, and an owner bundle 12 are created as a platform system by a PF provider. The PF set 14 is assumed. There is one PF set 14 in the present embodiment, and a plurality of SP bundle sets 13 can be considered.

  The Java VM 10 has a non-standard function that does not exist in the prior art (see the modified part in FIG. 1). Also, the memory management bundle 12a is prepared as one of the owner bundles 12 in order to give the Java VM 10 a unique API and to set predetermined information (described later) in the Java VM 10.

  The memory management bundle 12a transmits information on information of bundles constituting one bundle set (hereinafter referred to as bundle set information) and the amount of memory permitted to be used for the bundle set (hereinafter referred to as bundle set memory amount) to a communication network. It has a function of acquiring from the server 3 or the like connected via the server, temporarily storing it in the storage means, and reading and acquiring from the storage means.

  Here, the bundle set information is an identifier that uniquely identifies the bundle by the Bundle-SymbolName and Bundle-Version defined by the OSGi specification, and one or more identified bundles are designated.

  As shown in FIG. 3, the server 3 is installed outside as a separate device from the memory management device 1 and communicates with the memory management device 1. Various methods such as an XML file can be considered for delivery of bundle set information and the like. Note that the bundle set information or the like may not be acquired by communicating with the server 3, but may be stored and read in advance in the storage unit of the own device.

  In addition, the memory management bundle 12a acquires bundle set information and a bundle set memory amount, and then splits a heap having the same size as the acquired bundle set memory amount to the Java VM 10 through a first API (described later) provided by the Java VM 10. It has a function of making a request for generating an area and acquiring an ID for identifying the generated divided heap area (hereinafter referred to as a heap ID).

  Further, when a bundle belonging to a bundle set is installed on OSGiFW and a RESOLVE event is received, the memory management bundle 12a acquires the class loader object of the bundle through the OSGi standard API and the Java standard API (hereinafter, standard API). In addition, through a second API (described later) provided by the Java VM 10, the Java VM 10 has a function of transmitting information including a bundle class loader object and a heap ID.

  The Java VM 10 has a first API and a second API as an external design. The first API has a function that takes a bundle set memory amount as an argument, newly generates a divided heap area having a specified bundle set memory amount, and returns a heap ID of the generated divided heap area.

  The second API takes a class loader object and a heap ID as arguments, and requests to secure a memory area secured (consumed) by a bundle loaded from the designated class loader object from the divided heap area of the designated heap ID. It has a function to accept.

  On the other hand, the Java VM 10 has a data structure in which a heap ID can be set for a class loader object as an internal design. When the first API is called, it has a function of generating a divided heap area. When the second API is called, it has a function of setting the designated heap ID in the data structure of the designated class loader object.

  Further, a function for allocating a memory area secured (consumed) by a bundle to a divided heap area of a specified heap ID, or a heap ID determined by a heap selection algorithm (described later), and a divided heap area of the determined heap ID And a function of allocating a memory area to be secured (consumed) by the bundle.

  In addition, when the memory is insufficient in the divided heap area (for example, when the memory amount necessary for each SP bundle set cannot be secured), an OOM error is generated for each divided heap area.

[Operation of memory management device]
Next, the operation of the memory management device 1 will be described. In order to facilitate understanding, hereinafter, the SP bundle 131 of the SP bundle set 13 will be described as an example. In addition, the bundle set information in this case is described as SP bundle set information.

  First, the memory management bundle 12a acquires the SP bundle set information and the SP bundle set memory amount from the external server 3 connected via the communication network (S1).

  Next, after S1, when the SP bundle 131 of the SP bundle set 13 that was acquired in S1 is installed in the memory management device 1 and receives a RESOLVE event, the memory management bundle 12a calls the first API of the Java VM 10. Then, a request for generating a divided heap area having the size of the SP bundle set memory acquired in S1 is made, and a heap ID set for the generated divided heap area is acquired (S2).

  At this time, the Java VM 10 divides one heap area allocated from the OS, generates a divided heap area having the same size as the SP bundle set memory amount, and returns a heap ID (S2 ').

  After S2 and S2 ′, the memory management bundle 12a acquires the class loader object of the installed SP bundle 131 using the standard API, and specifies the acquired class loader object and the heap ID acquired in S2. Then, the second API of the Java VM 10 is called (S3).

  Finally, the Java VM 10 secures the installed SP bundle 131 in the divided heap area having the heap ID specified in S3 or the divided heap area having the heap ID determined based on the heap selection algorithm to be used (described later). A memory area to be consumed is allocated (S4). As a result, the SP bundle 131 executes its own program using the allocated divided heap area.

  As described above, a split heap area having the same size as the bundle set memory amount permitted to be used by the SP bundle set 13 is generated, and the generated split heap area or the split heap area determined based on the heap selection algorithm is generated. Since the memory area secured (consumed) by the SP bundle 131 of the SP bundle set 13 is allocated, the memory consumption consumed by the SP bundle 131 can be limited in arbitrary units.

  Further, since the divided heap area is generated, it is possible to have a plurality of heap areas which were one in the prior art.

  Moreover, since the divided heap area to be allocated is determined based on the heap selection algorithm, the limiting unit can be changed.

  Information set by the second API is referred to by a heap selection algorithm. Since only information that can be traced by pointer reference from the stack without using a table search is used, it is possible to reduce the speed reduction in memory allocation during program operation.

  In particular, since the memory area consumed by the SP bundle 131 is allocated to the divided heap area determined based on the heap selection algorithm, the heap area consumed by the PF set 14 or the SP bundle set 13 is assigned as a unit of effect of the heap algorithm. It becomes possible to restrict with.

  In the present embodiment, a bundle such as bundle set information acquired from the server 3, a bundle of split heap areas requested to be generated from the Java VM 10, a bundle loaded from the class loader, and a memory area are allocated and secured. All of the (consumed) bundles and the like have been described using the SP bundle 131 as an example as described above, but this is merely an example.

  Instead of or in addition to the SP bundle 131, it is also possible to use an owner bundle included in the SP bundle set 13, the PF set 14, and the PF set 14 which are bundle groups having one or more bundles.

  In the present embodiment, the method of generating one divided heap area by dividing one heap area has been described as an example, but this is only an example. A method of newly generating a heap area having the same size as the SP bundle set memory amount or a method of dividing the original heap area can also be used.

  In other words, any method can be used as long as a heap area of the same size as the amount of memory allowed to be used is allocated from the own heap area and a memory area used by the bundle group is allocated to the heap area. it can.

[Heap selection algorithm]
Next, a heap selection algorithm will be described.

  As described above, when the memory allocation is performed on the divided heap area, the unit in which the memory consumption can be limited changes depending on the heap selection algorithm for selecting the heap ID for performing the memory allocation. In the present embodiment, four heap selection algorithms will be described as an example.

  Here, the relationship between the PF set 14 and the SP bundle set 13 is considered. The following four types (2 × 2) can be considered as which of the PF set 14 and the SP bundle set 13 is the class providing side / calling side.

  Quadrant a) Caller: PF set.

          Class provider: PF set.

  Quadrant b) Caller: SP bundle set Y (SP_Y).

          Class provider: PF set.

  Quadrant c) Caller: PF set.

          Class provider side: SP bundle set X (SP_X).

  Quadrant d) Caller: SP bundle set (SP_Y).

          Class provider side: SP bundle set (SP_X).

  Since quadrant b and quadrant c are both SP bundle sets for the PF set, the SP bundle set may be X or Y, but is distinguished here for convenience.

  If each of these quadrants is represented by a stack, the stacks shown in FIGS. 4 to 7 are obtained. These are represented in a table as shown in FIG.

  In addition, as a specific example showing which divided heap area is selected in each heap selection algorithm described later, as shown in FIG. 9A (a), the bottom stack is a PF set of stack [0]. Use the stacked stack as the stack.

  The pattern in each stack indicates that the memory area consumed by each stack (ie, each class) is the SP bundle set 1 (hereinafter referred to as SP_BS1), SP bundle set 2 (hereinafter referred to as SP_BS2), or PF set. Indicates whether it is counted as consumption. The characters in each stack represent the provider of the class that generated each stack.

  That is, in the case of the stack of FIG. 9A in a thread operating on JavaVM, the PF set (its class, omitted below) calls SP_BS1 (its class, omitted below) in stack [0] and the stack [ 1], SP_BS1 of stack [1] calls the PF set to stack [2], the PF set of stack [2] calls the PF set to stack [3], and the PF set of stack [3] is SP_BS2 And SP_BS2 of stack [4] calls SP_BS1 to make stack [5], and SP_BS1 of stack [5] calls the PF set to make stack [6]. Then, processing is sequentially performed from the top stack [6] called last.

  Hereinafter, terms will be defined before describing the heap selection algorithm. The constant is capitalized and the initial letter of the variable is small letter (the constant here indicates a value that is not assigned in one heap selection algorithm). The heap selection algorithm is an algorithm for determining a variable heapID that is a heap ID for finally allocating memory.

  The heap ID set in the class loader is CL_HEAPID. Let CL_HEAPID of the PF set be HEAPID_PF. Let CL_HEAPID of the SP bundle set be HEAPID_SP. The CL_HEAPID of the class that is processed in each stack is defined as STACK_HEAPID.

  As the stack is traced down one by one, the variable representing the currently examined stack is curStack. A variable that is temporarily used to determine the heap ID is a cure ID. Let the top stack of each thread be TOPSTACK.

  If curStack follows the thread down and designates the next of the last stack, it will point to Null.

  Since heap memory allocation is executed in the top stack of the thread, the heap selection algorithm is always executed every time memory allocation is required in TOPSTOP.

<First heap selection algorithm>
A flowchart showing the operation of the first heap selection algorithm is shown in FIG. The subject of all the heap selection algorithms described below is JavaVM10.

  The STACK_HEAPID of the TOPSTACK is set as the heatID (S101).

  That is, as shown in FIG. 9A (b), the memory area secured (consumed) by each stack class is allocated to each divided heap area generated for each stack class.

  As described above, since the memory area secured (consumed) by each stack class is allocated to each divided heap area generated for each stack class, the set unit of the implementation class (that is, regardless of the caller) Memory consumption can be counted in units of bundle groups of PF sets and SP bundle sets), and the memory consumption can be limited by the counting method.

<Second heap selection algorithm>
FIG. 11 is a flowchart showing the operation of the second heap selection algorithm. The second heap selection algorithm is an algorithm for tracing down the stack one by one and searching for a call source stack. Each stack has a relationship of being called and called in a certain thread.

  First, TOPSTACK is substituted for curStack (S201).

  Next, if curStack is Null, the process proceeds to S204, and otherwise, the process proceeds to S203 (S202).

  Next, curStack is moved down one stack (S203).

  Finally, STACK_HEAPID of curStack is set as a heap ID (S204).

  That is, the caller stack of TOPSTACK is repeated, the caller stack of the caller stack is repeated, and the caller is traced. As a result, the heap ID set in the class loader of the stack at the bottom of the thread is referred to.

  In other words, the memory area secured (consumed) by all the stack classes is allocated to the divided heap area generated for the stack class that made the first call.

  When this algorithm is executed, an example of the stack is as shown in FIG. 9A (c). For example, how the memory area secured (consumed) by the stack [6] is counted will be described below.

  The stack [6] is called by the stack [5], and the stack [5] is called by the stack [4]. The stack [4] is called by the stack [3], and the stack [3] is called by the stack [2]. The stack [2] is called by the stack [1], and the stack [1] is called by the stack [0].

  Since there is no caller in the stack [0], as a result, the memory consumption of the stack [6] is counted as the call of the stack [0], and is counted as the memory consumption of the PF set of the stack [0].

  After the processing of stack [6] is performed, stack [6] disappears from the thread and stack [5] becomes TOPSTOP. Since the same processing is performed in the stacks [5] to [0], all the stacks [0] are counted as the calling memory.

  As described above, since the memory area secured (consumed) by all stack classes is allocated to the divided heap area for the stack class that first called the memory, the memory consumption can be counted on a per-thread basis. The consumption can be limited.

<Third heap selection algorithm>
A flowchart showing the operation of the third heap selection algorithm is shown in FIG. The third heap selection algorithm is an algorithm for selecting a divided heap every time memory allocation occurs in TOPSTOP.

  First, HEAPID_PF is substituted for heapID (S301).

  Next, TOPSTACK is substituted for curStack (S302).

  Next, STACK_HEAPID is substituted for curheapID (S303).

  Next, if curheapID is HEAPID_PF, the process proceeds to S305, and otherwise, the process proceeds to S306 (S304).

  Next, if the heapID is HEAPID_SP, the process is terminated as a divided heap area in which the value included in the heapID is selected by the present algorithm. Otherwise, the process proceeds to S306 (S305).

  Next, the cure ID is substituted into the heat ID (S306).

  Next, curStack is moved down one stack (S307).

  Finally, if curStack is Null, the process ends as the divided heap area in which the value included in the heapID is selected by the present algorithm, and if not, the process returns to S303 (S308).

  In other words, in the relationship between the PF set generated by the PF provider that is the function provider (with the bundle) and the SP bundle set generated by the SP provider that is the function user, the memory consumption is the call class. Regardless of the provision, it is counted as the memory consumption of the SP bundle set that uses the function.

  That is, the memory area secured (consumed) by the PF set (function providing bundle group) that provides the function is allocated to the divided heap area generated for the SP bundle set (function use bundle group) that uses the function. ing.

  It should be noted that the PF set serving as the base of the system cannot realize the function for the PF set by using the SP bundle set.

  For example, as an example of the quadrant b, it is conceivable that the PF set provides a bundle in which HttpService is implemented as a common function of the PF. The SP bundle obtains http service and uses the function of http service provided by the PF set by calling.

  A representative example of the quadrant c is a call to BundleActivator # start defined in the OSGi specification. The OSGiFW, that is, the PF set is called, but the reason why the SP bundle provides the class is to use the “function for starting the SP bundle on the target terminal” provided by the PF set.

  In any case, the quadrant c is a callback type as described in the background art, that is, the SP bundle set on the class providing side uses the function.

  However, when quadrants a and d, that is, when a PF set calls a PF set, or when an SP bundle set calls an SP bundle set, the memory consumption of the called SP bundle set is Count.

  FIG. 13 shows the relationship between the caller and the class providing stack. This figure shows, in the relationship between two stacks, whether the memory consumed in the upper stack (class providing stack) is counted as the stack of the caller stack or the class providing stack.

  Here, an example in which a plurality of stacks are stacked will be described with reference to FIG. 9A (d). First, the amount of memory consumed by the stack [6] corresponding to the class of the PF set is counted as the amount of memory consumed by the caller stack [5] because the caller stack [5] is the SP bundle set 1 (quadrant b) ).

  The amount of memory consumed by the stack [5] which is the SP bundle set 1 is counted as the memory consumed by the caller stack [4] since the caller stack [4] is the SP bundle set 2 (quadrant d). .

  The amount of memory consumed in the stack [4] is counted as the amount of memory consumed in the class providing stack [4] because the caller stack [3] is a PF set (quadrant c).

  Therefore, the memory amount consumed in the stacks [4] to [6] is counted as the memory amount consumed by the SP bundle set 2 that provides the class corresponding to the stack [4].

  Similarly, the amount of memory consumed by the stack [3] is counted as the consumed memory of the caller stack [2] because the caller stack [2] is a PF set (quadrant a).

  The amount of memory consumed in the stack [2] is counted as the consumed memory of the caller stack [1] because the caller stack [1] is the SP bundle set 1 (quadrant b).

  The amount of memory consumed in the stack [1] is counted as the amount of memory consumed in the class providing stack [1] because the caller stack [0] is a PF set (quadrant c).

  Therefore, the memory amount consumed in the stacks [1] to [3] is counted as the memory amount consumed by the SP bundle set 1 that provides the class corresponding to the stack [1].

  Finally, the amount of memory consumed by the stack [0] is counted as the amount of memory consumed by the stack [0], which is the class providing stack, since there is no caller stack.

  Therefore, the memory amount consumed by the stack [0] is counted as the memory amount consumed by the PF set that provides the class corresponding to the stack [0].

  As described above, since the memory area secured (consumed) by the PF set that provides the function is allocated to the divided heap area for the SP bundle set that uses the function, the memory consumption can be counted in units of bundle sets that use the function. The memory consumption can be limited by the counting method.

<4th heap selection algorithm>
In the third heap selection algorithm, the function provision / use relationship has been described using the PF set that provides the function and the SP bundle set that uses the function.

  On the other hand, since the same relationship exists between SP bundle sets, the fourth heap selection algorithm will explain that case.

  In order to realize the fourth heap selection algorithm described below, the following functions are added to the memory management bundle 12a and the Java VM 10.

  The memory management bundle 12a further has a function of obtaining information as to whether the class of the SP bundle 131 provides or uses a function. In addition, through a third API (described later) provided by the Java VM 10, it further has a function of requesting the Java VM 10 to set a function provision / use (Call Back Flag, hereinafter referred to as CBF) for each class.

  As an external design, the Java VM 10 has a third API that takes a class object and a CBF as arguments and sets in the Java VM 10 whether the designated class provides a function or uses a function. As an internal design, a data structure capable of setting CBF in the data structure of the class object is prepared, and has a function of setting the CBF specified in the data structure of the specified class object when the third API is called.

  The operation of the memory management device 1 when having such a function will be described below.

  First, the memory management bundle 12a acquires the SP bundle set information and the SP bundle set memory amount from the external server 3 connected via the communication network, and the SP of the SP bundle set 13 that is the acquisition target. The CBF set in the class of the bundle 131 is acquired (S11).

  Next, after S11, when the SP bundle 131 of the SP bundle set 13 to be acquired in S11 is installed in the memory management device 1 and receives a RESOLVE event, the memory management bundle 12a calls the first API of the Java VM 10. Then, a request for generating a divided heap area having the size of the SP bundle set memory acquired in S11 is made, and a heap ID set for the generated divided heap area is acquired (S12).

  At this time, the Java VM 10 divides one heap area allocated from the OS, generates a divided heap area having the same size as the SP bundle set memory amount, and returns a heap ID (S12 ').

  After S12 and S12 ′, the memory management bundle 12a acquires the class loader object of the installed SP bundle 131 using the standard API, and specifies the acquired class loader object and the heap ID acquired in S12. The second API of the Java VM 10 is called (S13).

  Further, the class loader object acquired in S13 and the CBF acquired in S11 are specified, and the third API is called (S14).

  Finally, after setting the CBF specified in S14 in the data structure of the class object specified in S14, the Java VM 10 is installed in the divided heap area of the heap ID determined based on the fourth heap selection algorithm described later. A memory area secured (consumed) by the SP bundle 131 is allocated (S15).

  The CBF indicates whether the class is a class providing or using the class. The memory provided by the function providing class is called from the SP bundle set and consumed by the stack of the function providing class is counted as the consumed memory of the called SP bundle set.

  On the other hand, the memory used by the function usage class is called from the SP bundle set and consumed in the stack of the function usage class is counted as the memory consumption of the called SP bundle set.

  That is, the memory area secured (consumed) by the SP bundle set (function providing bundle group) that provides the function is allocated to the divided heap area generated for the SP bundle set (function using bundle group) that uses the function. I have to.

  FIG. 14 is a flowchart showing the operation of the fourth heap selection algorithm. The fourth heap selection algorithm selects a divided heap every time memory allocation occurs in TOPSTOP. CUR_CBF represents the CBF of the curStack class, and last_CBF represents the CBF of the stack class one level above the curStack.

  First, HEAPID_PF is substituted for heapID (S401).

  Next, TOPSTACK is substituted into curStack (S402).

  Next, function provision is substituted into last_CBF (S403).

  Next, STACK_HEAPID is substituted for curheapID (S404).

  Next, if curheapID is HEAPID_PF, the process proceeds to S410, and if not, the process proceeds to S406 (S405).

  Next, if curheapID is the same as heapID, the process proceeds to S410, and if not, the process proceeds to S407 (S406).

  Next, if heapID is HEAPID_PF, the process proceeds to S409, and if not, the process proceeds to S408 (S407).

  Next, if the last CBF is a function use, the process is terminated, and if not, the process proceeds to S409 (S408).

  Next, the cure ID is substituted for the heat ID (S409).

  Next, CUR_CBF is substituted into last_CBF (S410).

  Next, curStack is moved down one stack (S411).

  Finally, if curStack is Null, the process is terminated; otherwise, the process returns to S403 (S412).

  FIG. 15 shows the relationship between the caller and the class providing stack.

  Here, an example in which a plurality of stacks are stacked will be described with reference to FIGS. 9B (e) and 9 (f). First, how stack [5] is counted in FIG. 9B (e), which is a function usage class, will be described.

  The amount of memory consumed by the stack [6] corresponding to the class of the PF set is counted as the amount of memory consumed by the caller stack [5] because the caller stack [5] is the SP bundle set 1 (quadrant b).

  The amount of memory consumed by the stack [5] which is the SP bundle set 1 is counted as the memory consumed by the class providing stack [5] because the calling stack is the SP bundle set 2 and is a function use class. (Quadrant d). Stack [4] to stack [0] are the same as the third heap selection algorithm.

  Next, how stack [5] is counted in FIG. 9B (f), which is a function providing class, will be described.

  The amount of memory consumed by the stack [6] corresponding to the class of the PF set is counted as the amount of memory consumed by the caller stack [5] because the caller stack [5] is the SP bundle set 1 (quadrant b).

  The amount of memory consumed by the stack [5] which is the SP bundle set 1 is counted as the memory consumed by the called SP bundle set 2 because the calling stack is the SP bundle set 2 and is a function providing class. (Quadrant d). Stack [4] to stack [0] are the same as the third heap selection algorithm.

  As described above, since the memory area secured (consumed) by the SP bundle set that provides the function is allocated to the divided heap area for the SP bundle set that uses the function, in addition to the effect of the third heap selection algorithm, In the call, the count destination of the memory consumption can be changed by providing and using the function, and the memory consumption can be further limited.

  In addition, since a data structure that can set CBF as the data structure of the class object is prepared in the Java VM 10, it is possible to determine whether the function is provided or used for each class.

[Measurement of memory consumption]
Next, a memory consumption measurement method in the Java VM 10 will be described. In order to measure the memory consumption, the following functions are added to the Java VM 10.

  As an external design, the Java VM 10 further includes a fourth API that takes the heap ID as an argument and calculates the memory amount of the divided heap area. Further, as an internal design, it has a function of returning the free memory amount of the specified heap ID when the fourth API is called.

  Hereinafter, a method for measuring the memory consumption of the divided heap area will be described.

  First, the Java VM 10 performs GC (S21). For example, before the fourth API is called, the program that calls the fourth API has a System. A method of performing GC with gc () or the like is also conceivable. Here, it does not matter whether GC is performed for each divided heap area or the entire heap area.

  Next, after S21, the heap ID transmitted from the memory management bundle 12a is acquired, and the consumed memory and the remaining available memory in the divided heap area of the heap ID are calculated (S22).

  Finally, the consumed memory and available memory calculated in S22 are returned to the memory management bundle 12a (S23).

  Note that GC is a process of automatically releasing an unnecessary area from among memory areas dynamically allocated by a program.

  From the above, memory consumption can be measured in units of divided heap areas.

[Deleting the generated divided heap area]
Next, a method for deleting the generated divided heap area will be described. In order to delete the divided heap area, the following function is added to the Java VM 10.

  As an external design, the Java VM 10 further includes a fifth API that takes a heap ID as an argument and deletes the divided heap area. Further, as an internal design, it has a function of deleting the divided heap area of the specified heap ID when the fifth API is called.

  As described above, the split heap area to be deleted is released.

〔Example〕
<Example in Calling from PF Set to SP Bundle Set>
Consider an example in which the SP bundle set 1 (hereinafter referred to as SP1) calls the SP bundle set 2 (hereinafter referred to as SP2) in the third and fourth heap selection algorithms.

  When a PF set is called inside SP2, a stack as shown in FIG. 16 may be obtained. The class of the PF set having such a stack structure includes, for example, AccessController. doPrivileged () and the like.

  For such a class, the CBF described in the fourth heap selection algorithm is set to provide a function, and the fourth heap selection algorithm is applied.

  As described above, a call from stack [3] to stack [4] is counted as SP2 memory consumption in the fourth heap selection algorithm. In this example, when SP1 uses the function of SP2, the stack [2] to stack [4] are called in order for SP1 to use the function of SP2.

  That is, it is desirable that the memory amount consumed in the stacks [2] to [4] is counted as the memory consumption amount of the SP1 that uses the function, and this can be realized.

<Example in which a PF set is divided in detail>
A class loaded from the bootstrap class loader is regarded as a JavaVM class, and a class loaded from the system class loader is regarded as an OSGiFW class. A different heap ID is set in the structure of each class loader object, and the first heap selection algorithm is used.

  As described above, the memory consumption can be limited for each class loaded from the same class loader. In particular, in the first heap selection algorithm, there is one PF set, but the PF set can be divided into JavaVM and OSGiFW.

<Example of linking thread and heap ID>
A data structure capable of setting a heap ID for a thread is added to the Java VM 10 as an internal design. In this case, the fifth heap selection algorithm shown in FIG. 17 is used.

  This algorithm selects a divided heap with a heap ID set for a thread. When a thread is set up, the heap ID of the class loader object of the class that sets up the thread is set in the structure of the set up thread.

  As described above, basically, the same effect as that obtained when the second heap selection algorithm is used can be obtained. The heap ID for allocating memory can be determined.

<Example of heap memory management method>
There are a plurality of methods for setting the memory value of the divided heap area.

  In the memory value free setting method, the memory value can be set freely. Since the memory value can be set freely, the memory can be used efficiently.

  The blocked heap method is a method in which a plurality of fixed-size divided heaps are prepared in advance, and has an advantage that there is no overhead of regeneration of the heap memory compared to the memory value free setting method.

<Example of GC>
The GC is considered to be performed for each divided heap area or for the entire heap area.

  The method performed for each divided heap area can operate without being affected by other heap areas even when GC occurs frequently in a certain divided heap area, compared to the method performed for the entire heap area.

  On the other hand, the method performed for the entire heap area has the following advantages compared to the method performed for each divided heap area. In a situation where GC occurs frequently in different divided heap areas, such as when a GC occurs in the second divided heap area immediately after the first divided heap area, the operation of searching for the referenced object from the root is performed. It happens frequently and becomes overhead. However, when GC is performed on the entire heap area, all the objects are searched at once, so that there is an advantage that such overhead is eliminated.

DESCRIPTION OF SYMBOLS 1 ... Memory management apparatus 10 ... JavaVM (Java virtual machine)
11 ... OSGiFW
12 ... Owner bundle 12a ... Memory management bundle 13 ... SP bundle set 131 ... SP bundle 14 ... PF set S1 to S4, S11 to S15, S101, S201 to S204, S301 to S308, S401 to S412, S501 ... step

Claims (7)

In a memory management device that manages memory used by a bundle based on the OSGi standard specification,
A memory management bundle that reads out information on the amount of memory permitted to be used for a bundle group having one or more bundles from the storage unit, and makes a request to secure a heap area having the same size as the amount of memory;
A Java virtual machine that secures the heap area from its own heap area and allocates a memory area used by the bundle group to the heap area;
A plurality of the bundle groups, the plurality of bundle groups have a relationship to be called and called in a certain thread,
The memory management bundle is
The request is made only for the bundle group that made the call first, and the request is not made for bundle groups other than the bundle group,
The Java virtual machine is
A memory management device characterized by allocating a memory area used by all bundle groups to a heap area reserved for a bundle group that is first called. In a memory management device that manages memory used by a bundle based on the OSGi standard specification,
A memory management bundle that reads out information on the amount of memory permitted to be used for a bundle group having one or more bundles from the storage unit, and makes a request to secure a heap area having the same size as the amount of memory;
A Java virtual machine that secures the heap area from its own heap area and allocates a memory area used by the bundle group to the heap area;
The bundle group includes a plurality of bundle groups, and the bundle groups are a function providing bundle group and a function using bundle group that have a relationship of providing and using functions of the bundle in a certain thread,
The memory management bundle is
Make the request only for the function use bundle group, do not make the request for the function provision bundle group,
The Java virtual machine is
A memory management device, wherein a memory area used by the function providing bundle group is allocated to a heap area reserved for the function using bundle group. In a memory management method for managing memory used by a bundle based on the OSGi standard specification,
By computer
A first step of reading out information on a memory amount permitted to be used for a bundle group having one or more bundles from a storage unit, and making a request to secure a heap area having the same size as the memory amount;
Securing the heap area from its own heap area, and allocating a memory area used by the bundle group to the heap area, and
A plurality of the bundle groups, the plurality of bundle groups have a relationship to be called and called in a certain thread,
The first step includes
The request is made only for the bundle group that made the call first, and the request is not made for bundle groups other than the bundle group,
The second step includes
A memory management method characterized by allocating a memory area used by all bundle groups to a heap area reserved for a bundle group that is first called. In a memory management method for managing memory used by a bundle based on the OSGi standard specification,
By computer
A first step of reading out information on a memory amount permitted to be used for a bundle group having one or more bundles from a storage unit, and making a request to secure a heap area having the same size as the memory amount;
Securing the heap area from its own heap area, and allocating a memory area used by the bundle group to the heap area, and
The bundle group includes a plurality of bundle groups, and the bundle groups are a function providing bundle group and a function using bundle group that have a relationship of providing and using functions of the bundle in a certain thread,
The first step includes
Make the request only for the function use bundle group, do not make the request for the function provision bundle group,
The second step includes
A memory management method, comprising: allocating a memory area used by the function providing bundle group to a heap area reserved for the function using bundle group. The function provision bundle group is a bundle group generated by a platform provider that provides a function, and the function use bundle group is a bundle group generated by a service provider that uses a function, or
The function provision bundle group is a bundle group generated by a service provider that provides a function, and the function use bundle group is a bundle group generated by a service provider that uses a function. The memory management method according to claim 4. 6. The memory management method according to claim 3, further comprising a step of calculating a memory consumption amount used in the heap area. A memory management program for causing a computer to execute each step according to claim 3.

Images