WO2007034769A1 - ゼロガベージコレクション通信仲介装置 - Google Patents

ゼロガベージコレクション通信仲介装置 Download PDF

Info

Publication number
WO2007034769A1
WO2007034769A1 PCT/JP2006/318485 JP2006318485W WO2007034769A1 WO 2007034769 A1 WO2007034769 A1 WO 2007034769A1 JP 2006318485 W JP2006318485 W JP 2006318485W WO 2007034769 A1 WO2007034769 A1 WO 2007034769A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
concurrent
temporary
limit
objects
Prior art date
Application number
PCT/JP2006/318485
Other languages
English (en)
French (fr)
Inventor
Satoshi Hirano
Runtao Qu
Takeshi Ohkawa
Original Assignee
National Institute Of Advanced Industrial Science And Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Institute Of Advanced Industrial Science And Technology filed Critical National Institute Of Advanced Industrial Science And Technology
Publication of WO2007034769A1 publication Critical patent/WO2007034769A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory

Definitions

  • the present invention provides a request with improved real-time characteristics for a remote request between computers executed in an execution environment by a programming language having garbage collection or hardware having a used memory management means.
  • This is related to a request mediation device that performs mediation. More specifically, distributed real-time processing that operates between multiple computers on a network by suppressing the occurrence of a garbage collection that starts when the work memory is insufficient.
  • the present invention relates to an intermediary device that improves real-time performance in processing of communication middleware, programming languages, operating systems, and communication mediation hardware used for system construction by application programs. Background art
  • the request mediating apparatus targeted by the present invention is an apparatus having advanced communication functions related to distributed processing and parallel processing, such as distributed objects, parallel objects, web services, agent systems, P2P systems, and audio / video distribution apparatuses. It is.
  • the device is realized by middleware, parallel Z distributed operating system (hereinafter abbreviated as OS), parallel Z distributed language, software or hardware with many libraries (Fig. 1). Examples of communication middleware include web services, CORBA, RMI, HORB, and P2P systems. In the present invention, these are referred to as “request mediation device” or “mediation device”.
  • the term “request” means a remote procedure call, a remote method invocation, a remote service invocation, and the like.
  • the request intermediary device is responsible for mediating requests issued by the client computer to the server and computer, not the processing of the application that services the request itself, and transmitting the response to the client computer.
  • This one-line program piece calls the mediation device and automatically performs relatively complicated communication processing via the network.
  • a computer broadly means a small microcomputer in an embedded device, not just a personal computer and a server, and a plurality of communicating components in the same system.
  • GC garbage collection
  • the "garbage collector” periodically checks all objects, and if an object is "referenced by any reference type variable," the object is delete. As a result, the memory (heap memory) used by the object is released and can be used again.
  • GC garbage collection
  • the object is generated on the heap memory. If heap memory runs out of a limited amount of heap memory, program processing may terminate abnormally. However, GC automatically collects the memory occupied by objects that are no longer used, and collects the heap memory. The memory is reused because it is returned to memory. By releasing the memory management capability of the programmer in this way, the productivity of programmers using the Java (registered trademark) language has been greatly improved compared to the case of using the C language or C ++ language.
  • this GC processing occurs at the discretion of a language runtime (for example, a Java virtual machine), and is executed by interrupting program execution. For this reason, unpredictable GC may occur in distributed real-time application processing, and unpredictable communication interruption may occur during communication processing. It may cause an accident.
  • a language runtime for example, a Java virtual machine
  • an intermediary device product implemented in an existing object-oriented programming language
  • a large amount of temporary objects are generated for each request (remote method call), so GC frequently occurs.
  • the temporary object refers to all types of objects generated in the intermediary device along with the request mediation process.
  • the Sano object that provides remote services large data such as a communication buffer, and trivial data such as the host name, user name, session identifier, and request number of the communication partner are stored in the heap memory. Contains all stored objects. These are implemented using string objects, structural objects, array objects, etc., and are generated for each session or each request, and are collected by the GC after use.
  • a non-temporary object is an object that persists beyond the lifetime of the session or request.
  • the mediation device for example, in the case of a table that records outside the active single object, it is created when the mediation device starts. Survive until the end.
  • the following table shows the results of investigating the number of temporary objects generated during one request (remote method call) and the amount of temporary memory used in several Java mediation devices. .
  • the request mediation device developed in the programming language executed in the execution environment with GC is a major factor that is not used in applications that require real-time capability. Even when the mediation device is implemented by hardware, a means for managing the used memory, that is, GC by hardware, is necessary, and includes the same problem.
  • Patent Document 13 by implementing the “ reC y C le () method”, the class can be reused so that the GC process can determine whether an object can be reused.
  • Patent Document 13 This is a good mechanism for reusing objects and preventing objectat generation. If the garbage collector happens to find a reusable object, GC over the entire memory area will It will occur. Therefore, the invention of Patent Document 13 can reduce the cost of object generation, but cannot prevent interruption of communication by GC.
  • Patent Document 10 proposes an invention of a method for removing the generation of a fixed / constant object from a method call. According to the invention of Patent Document 10, the problem of excessive use of memory in an iterative process can be partially solved. However, in most mediators, requests are dynamic processes that handle a variety of types, and most temporary objects in the process are neither fixed nor constant.
  • a streaming distribution system such as video provides QoS (Quality of Service: communication with ensured quality) for an application.
  • QoS intermediary devices and OS drivers guarantee communication quality by preferentially allocating CPU time and network bandwidth.
  • memory allocation the OS allocates the amount of memory for the communication buffer of each stream according to the QoS level. The scope of this technology is limited to buffers for communication data, and many small, temporary objects generated during requests are handled! /, N! /.
  • Real-time Java standards have been proposed by several organizations. Real-time Java counters this problem with a number of complex strategies. For example, Immortal Memory ( Permanent memory), scoped memory (range memory) and real-time threads. Since GC also occurs in the real-time Java platform, as long as the object is created and discarded, the request mediation process will cause a communication interruption problem due to GC. In many cases, ordinary Java products are used instead of real-time Java.
  • Real-time GC and parallel GC techniques are another good means of solving the problems addressed by the present invention.
  • Real-time GC improves interrupt response performance by subdividing GC time on a single CPU.
  • Concurrent GC allocates one CPU to GC processing on a multi-CPU system so that other CPUs do not interrupt execution by GC.
  • Non-Patent Document 1 in order to deal with the problem of lack of real-time property due to GC in embedded Java applications, design guidelines centered on object 'pooling, GC-less AWT (Abstract Windowing Toolkit) drawing library GC-less UDP (User Datagram Protocol) packet 'server is being developed.
  • GC-less AWT Abstract Windowing Toolkit
  • UDP User Datagram Protocol
  • Patent Documents 1 to 16 relate to memory management means or real-time processing in a computer system. However, they are not intended to solve the GC problem described here. In view of the trends in the prior art, we think it is well worth supplying an improved method for this problem.
  • Patent Document 1 Japanese Patent Laid-Open No. 63-93055
  • Patent Document 2 JP 2001-188704 A
  • Patent Document 3 Japanese Patent Laid-Open No. 2001-202284
  • Patent Document 4 U.S. Patent No. 6678697
  • Patent Document 5 US Patent No. 5950231
  • Patent Document 6 US Patent No. 6272674
  • Patent Document 7 US Patent No. 6055492
  • Patent Document 8 US Patent No. 6754796
  • Patent Document 9 U.S. Patent No. 6751790
  • Patent Document 10 U.S. Pat.No. 6,701,520
  • Patent Document 11 US Patent No. 6430564
  • Patent Document 12 US Pat. No. 6,748,555
  • Patent Document 13 U.S. Patent No. 6138127
  • Patent Document 14 US Patent No. 6611898
  • Patent Document 15 U.S. Pat.No. 6529948
  • Patent Document 16 U.S. Pat.No. 6381735
  • Non-Patent Document 1 Embedded Java Practical Consortium, Embedded Technology 2004 Lecture Report Ensuring embedded Java real-time performance and guidelines for implementation-GUI / network GC-less library implementation-Lecture material http://www.ejpc.Org/et2004/ et2004.htmlhttp: //www.ejpc.org/et2004/et2004p2.pdf
  • Non-Patent Document 2 ReaH: imePlatform SIG, Realtime CORBA, white paper, Object Manag ement Group, Dec. 199b, Editor: Judy McGoogan, Lucent Technologies.
  • Non-Patent Document 3 Ray Clark, E. Douglas Jensen, Doug Wells, Andy Wellings, The distrib uted Real— timeSpecification for Java: A Status Report, Embedded Systems Conferen ce, March 2002.
  • JSR 50 Distributed Real-Time Specification
  • GC If no object is generated, GC does not occur. If GC does not occur, communication is not interrupted. However, in general, the content of communication varies, and the amount of memory used varies greatly depending on the content. Also, depending on the application, the number of types of requests and the types of transferred data will increase as the application is improved. It is difficult to suppress GC with a low level such as a simple TCP packet library. This is difficult because a variety of objects are generated in an intermediary device such as a distributed object or a web service that has meaning in communication contents. is there.
  • the present invention has been made to solve such a problem, and the first problem of the present invention is a distributed real-time application that requires response communication and periodic communication within a certain time.
  • a request mediation device that can guarantee that communication interruption does not occur during request mediation processing for all communication patterns within the range assumed at the time of design may be provided.
  • the system configuration of such a request mediation device is called a hard zero GC system.
  • the second problem of the present invention is that communication interruption is reduced even for an application having a communication pattern that deviates from the range assumed at the time of design or an application that cannot assume a clear range at the time of design. It is to provide a request mediating apparatus. According to such a request mediation device, communication interruption does not occur due to the processing characteristics of the application, not just the processing characteristics of the request mediation device, or the power depending on the application characteristics Communication interruption power S This includes request mediation devices that can perform request mediation processing for applications that may wake up. The system configuration of such a request mediation device is called a soft zero GC system.
  • a third problem of the present invention is to provide a mode that suppresses communication interruption and a mediation apparatus that is operable in a mode that does not use the communication interruption suppression function in the request mediating apparatus of 1. It is. This is because real-time performance is not always required even within one application.
  • One distributed application must be real-time When necessary communication and unnecessary communication are used together, computing resources and development costs double, but an intermediary device that can reduce the increase in computing resources and development costs is provided.
  • the object of the present invention to solve the above-mentioned problems is to suppress the occurrence of garbage collection for remote request mediation between computers executed in an execution environment of an object-oriented programming language having garbage collection.
  • Another object of the present invention is to provide an intermediary device for zero garbage collection communication that performs request mediation by improving real-time performance without generating garbage collection. Means for solving the problem
  • an intermediary device for zero garbage collection communication is implemented by an object-oriented programming language having a garbage collection function.
  • An intermediary device that performs intermediary processing of remote requests between computers with garbage collection suppressed, and holds used temporary objects among temporary objects temporarily used for the mediation processing.
  • a temporary object storage means a temporary object management means for initializing the used temporary object for reuse, a request type limit value setting means for setting a request type limit value, and a request type Request type restriction means to restrict the request type by the limit value, Transfer data number limit value setting means for setting a limit value for the number of data and transfer data number limit means for limiting the type and number of data and objects transferred by the request according to the limit value for the transfer data number
  • a concurrent and concurrent usage limit setting means for setting a usage limit
  • a concurrent and concurrent usage limiting means for limiting the number of concurrent and concurrent requests by the concurrent and concurrent usage limit.
  • the first problem can be solved by using the locality of the communication pattern specific to the application and artificially limiting the communication pattern.
  • the use of memory can be optimized by utilizing the characteristic that there is a predetermined pattern. In other words, if the same request is repeated, instead of creating the necessary temporary object for each request, the temporary object created before communication or the first time created for the first time is not discarded after use. You can also suppress the occurrence of GC by using it again. This is hereinafter referred to as “zero GC”.
  • the communication pattern varies greatly depending on the application. If an unexpected communication occurs when there are too many objects to be transferred or there is an unexpected communication such as a larger number of clients' computers communicating at the same time, the number of temporary objects generated will increase and the heap memory will be exhausted. Therefore, by determining the range of communication patterns assumed for each application, many temporary objects are prevented from being generated.
  • the range of communication patterns to be restricted includes whether communication can be accepted (whether there are too many simultaneous sessions), what type of request communication is performed, and the data transferred by communication It is sufficient to limit the type and number.
  • the field of applications to which the present invention can be applied is also restricted at the same time. In many applications, the communication processing within them is regular, and this is often sufficient.
  • the mediating device (“zero GC communication mediating device”) according to the present invention has, as a first aspect, a system that mediates communications implemented in an object-oriented programming language having a GC mechanism.
  • the following processing is performed by the processing elements (each processing means) provided in.
  • the object management means searches the temporary object storage means, and if a temporary object that has been used in the same type is stored, it is extracted and reused. After use, it is stored again in the temporary object storage means. If an object of the same type as the temporary object does not exist in the temporary object storage means, the temporary object management means creates a new object for use. The newly created temporary object is stored in the temporary object storage means after use. For a hard zero GC system, memory usage cannot exceed the heap memory allocation given to the system.
  • the request type is restricted by the request type restriction means, and is transferred as an argument or a return value by the data transfer number restriction means.
  • the number and types of data and objects to be used are limited, and the number of simultaneous sessions is limited by means of limiting the number of concurrent and concurrent use.
  • there are two forms of restriction by these restriction means one is performed at the time of execution and the other is performed at the time of development. Requests restricted at runtime are postponed or notified to the client as exceptions or errors.
  • These limit values are set using the request type limit value setting means for the request type limit value, and the limit value for the number of transferred data by the request type limit value setting means. Are set by the simultaneous parallel usage limit value setting means.
  • the opportunity for generation of a temporary object is managed, and any number of request mediation processes can be performed as long as they are within the assumed communication pattern. No interruption occurs. Unexpected communication patterns are excluded. For this reason, it becomes a hard zero GC state, and communication with high real-time characteristics is possible.
  • the present invention provides a mediation device for zero garbage collection communication according to the present invention, in which the request type is restricted by the request type restriction means.
  • the number and the number of data and objects transferred by the request are limited by the transfer data number limiting means, or the number of simultaneous and concurrent requests is limited by the simultaneous and parallel use number limiting means.
  • Request If it cannot be started, it is configured to include a request postponing means for postponing the start of request processing within a time window.
  • the request deferment means is provided, and the request process can be deferred within the next time range if the request cannot be received by the restriction means as described above. Composed.
  • the request deferral means By deferring requests using the request deferral means, the chances of not being able to use the service due to refusal of reception can be reduced while ensuring real-time performance. Since the degree of real-time characteristics varies depending on the application, it is possible to adapt to various real-time characteristics by making it possible to adjust the time range (time window) that can be postponed.
  • an intermediary device for zero garbage collection communication according to the present invention further comprises a stub for generating a stub code that uses the temporary object management means.
  • You may be set as the structure which comprises a production
  • an intermediary device that implements a remote service using a stub code (also called a proxy, skeleton, or surrogate) uses a temporary object management means to By generating code that does not occur, GC is suppressed.
  • a stub code also called a proxy, skeleton, or surrogate
  • an intermediary device for zero garbage collection communication according to the present invention.
  • a request mediation process that further requires a temporary object is started.
  • a temporary object is generated and configured to be pre-positioned in the temporary object storage means.
  • the temporary object management means can be arranged in advance in the temporary object storage means to reduce the runtime object placement cost.
  • the present invention provides, as a fifth aspect, an intermediary device for zero garbage collection communication according to the present invention, wherein the concurrent parallel use number limiting means is a client.
  • the concurrent concurrent usage limit is determined based on the number of clients or the number of sessions used simultaneously, and is configured to determine the maximum number of temporary objects to be pre-arranged in the temporary object storage means.
  • the number of temporary objects required for zero GC operation in the mediating device is determined by the number of communication partners, that is, the number of users who use simultaneously and the number of other parties who communicate simultaneously. It is possible to cope with an environment having a plurality of users and a plurality of communication partners.
  • the amount of heap memory the product of the amount of memory used in one session and the number of simultaneous sessions is required.
  • an intermediary device for zero garbage collection communication includes a request type limit value limited by a request type limiting unit and a transfer value in the intermediary device.
  • the limit value of the type and number of data and objects transferred by the request restricted by the data number restriction means, the restriction value of the concurrent and concurrent use of requests restricted by the restriction means, and the temporary object Parameters of limit values for the type and number of temporary objects to be pre-arranged in the tag storage means include source code, interface definition, service definition, program meta information, command line option specification, setting screen, setting file, compilation Obtained by analyzing at least one of the programs Sea urchin made.
  • each limit value in each limiting means based on information about the temporary object used, and what type of object is stored in the temporary object storage means. You can decide how many to pre-position. Information on the temporary objects used is analyzed during development or early execution of source code, interface definitions, service definitions, program meta information, command line option specifications, configuration screens, configuration files or compiled programs. Can be obtained. You can obtain information about the type of objects and the number of temporary objects used in the parameters passed by the request, temporary objects used in the parameters passed by the request, and temporary objects used in the mediation device.
  • the present invention provides, as a seventh aspect, an intermediary device for zero garbage collection communication according to the present invention, wherein the temporary object management means includes a temporary object management means. If the object is an immutable object, it is configured to replace the temporary object with a variable object. With such a configuration, the intermediary device according to the present invention provides a variable object in place of an immutable object so that the variable object can be reused.
  • the mediation device may need to generate an immutable object.
  • the mediation apparatus in order to provide a variable object in place of an immutable object, when a temporary object management means is a temporary object when the temporary object is an immutable object, The variable object is reused so that is replaced with a variable object.
  • the intermediary device for zero garbage collection communication further switches between a mode in which garbage collection suppression processing is performed and a mode in which garbage collection suppression processing is not performed.
  • the operation mode switching means is provided, and the operation mode switching means uses the non-use of the temporary object management means according to each operation mode, the limit value set in the request type limit value setting means, and the transfer data number limit value. It is configured to set each setting value of the limit value set in the setting means and the limit value set in the simultaneous and parallel use limit value setting means.
  • the intermediary device can switch between a mode in which the garbage collection suppression process is performed and a mode in which the garbage collection suppression process is not performed by the operation mode switching means.
  • the same application It may be necessary to perform communication without zero GC processing within the network, and it is wasteful that one application has both a zero GC communication mediation device and a normal mediation device.
  • the zero GC communication intermediary device switches between the mode in which zero GC communication is performed and the mode in which zero GC processing is not performed! /, So that the appropriate operation mode can be selected for the application.
  • some limiting means such as limiting the types of requests is provided, for example, to ensure that GC does not occur in communication mediation processing, but depending on the application, If restrictions are imposed by all means of restriction, the system may not be realized. For this reason, it is possible to cover a wider range of applications, if necessary, by using only one or two limiting means rather than all three limiting means.
  • the present invention provides, as a ninth aspect, mediating apparatus power for zero garbage collection communication according to the present invention.
  • An intermediary device that performs garbage collection while suppressing garbage collection, the temporary object storage means for holding a used temporary object among the objects used for the mediation processing, and the used temporary object
  • a temporary object management means that is initialized for reuse; and a request restriction means that restricts requests accepted in the mediation process.
  • the request restriction means includes a request type restriction means that restricts the type of request, a request Data transferred by and Transfer data speed limiting means limits the type and number of objects, or be configured to be either concurrent use number limiting means for limiting the concurrent use number of requests. Such a configuration can cover a wider range of applications.
  • the intermediary device power for zero garbage collection communication according to the present invention
  • the configuration is as follows. Such a configuration can cover a wider range of applications.
  • the present invention provides, as an eleventh aspect, a memory allocation method so that the intermediary device for zero garbage collection communication according to the present invention can appropriately manage the memory usage in the intermediary device.
  • the memory allocation method according to the present invention for this purpose is a memory allocation method in an intermediary device that performs mediation processing of remote requests between computers implemented by an object-oriented programming language having a garbage collection function while suppressing garbage collection.
  • the maximum amount of heap memory that the mediation device should have is the amount of data transferred as an argument and return value in one request in addition to the amount of memory required by the mediation device itself in the initial state.
  • the maximum concurrent memory usage is added to the amount of memory added for each request type included in the request type limit value, plus the amount of memory required by the intermediary device for each session. Allocate the amount of memory obtained by multiplication.
  • the maximum heap memory amount to be provided in the mediation device according to the present invention can be obtained by the calculation formula, and the memory usage in the mediation device can be appropriately managed.
  • the mediation apparatus according to the present invention may be implemented by hardware other than simply using software for implementation.
  • the intermediary device of the present invention is used for constructing a distributed real-time application that operates between a plurality of computers on a network by suppressing the occurrence of garbage collection that starts when a memory shortage occurs.
  • Real-time performance in communication middleware, programming language, and operating system processing can be improved.
  • FIG. 1 is a diagram illustrating the positioning of an intermediary device for zero garbage collection communication according to the present invention.
  • FIG. 2 is a diagram illustrating a system configuration of an intermediary device for zero garbage collection communication according to the present invention.
  • FIG. 3 is a diagram showing how the time object storage means and the temporary object management means cooperate with the garbage collection means and the language runtime.
  • FIG. 4 is a flowchart illustrating a process for mediating a connection request to a service.
  • FIG. 5 is a first flowchart for explaining a step for performing pre-placement and reuse of a temporary object in a system with pre-placement.
  • FIG. 6 is a second flowchart for explaining a step for performing pre-placement and reuse of a temporary object in a system with pre-placement.
  • FIG. 7 A flow chart for explaining processing for obtaining information about a time object and determining a limit value.
  • FIG. 8 is a diagram showing an example of an application (client “program”).
  • FIG. 9 is a flowchart showing processing for managing a temporary object in mediation processing of a service request.
  • FIG. 10 is a diagram illustrating an example of using immutable objects.
  • FIG. 11 is a flowchart explaining the steps of request mediation processing with relaxed restrictions
  • FIG. 12 is a flowchart for explaining a switching process between a mode in which zero GC processing is performed and a mode in which zero GC processing is not performed in request mediation processing.
  • FIG. 13 is a diagram showing the positioning of stub codes and stub code generation means.
  • FIG. 14 is a flowchart for explaining an intermediary process including a postponement process performed when a request exceeds a limit value.
  • FIG. 15 is a diagram showing an expression for calculating the maximum heap memory amount to be used.
  • the present invention mainly avoided distributed real-time 'applications where communication interruptions should be avoided, non-real-time distributed applications where communication interruptions are undesirable, and avoiding GC for improved processing speed and response speed. Applies to middleware, communication libraries, languages, or operating systems used in distributed applications.
  • FIG. 1 is a diagram for explaining the positioning of an intermediary device for zero garbage collection communication according to the present invention. It shows the position of the intermediary device in the distributed application.
  • a client 'computer 110 and a server' computer 120 are coupled by a communication medium 130, and data communication is performed between the two computers. Communication takes place between two or more computers, or between multiple communication elements within a single computer. Communication information itself is transmitted via the communication medium 130.
  • the communication medium 130 for example, a network is used for communication between a plurality of computers, and a data node is used for communication between a plurality of communication elements in one computer.
  • the computer on the side issuing the request for convenience is used for the two computers. It is divided into the client computer 110 and the server 120 that accepts and services the request.
  • the application includes an application (client program) 111 operating on the client side and an application (server program) 121 operating on the server side. Communication processing performed in the application is mediated by the client-side mediating device 112 and the server-side mediating device 122.
  • the client-side mediating device 112 is configured with a client-side stub and a client-side communication runtime
  • the server-side mediating device 122 is configured with a server-side stub and a server-side runtime capability.
  • An application that calls a server-side stub, and an application (sano program) 121 contains a sano object that executes a service. The same configuration is used for both Web services and video servers.
  • FIG. 2 is a diagram for explaining the system configuration of an intermediary device for zero garbage collection communication according to the present invention.
  • An example of the configuration on one computer equipped with the zero GC communication mediation device is shown.
  • 200 indicates one computer on the server side or the client side
  • 220 is a language runtime used by the zero GC communication mediator 230.
  • language runtime 220 examples include "Java virtual machine”, “.NET CLR”, “GNU Mono runtime”, and the like.
  • the intermediate code execution method, compile-time native code conversion method, and runtime native code conversion method can be used.
  • Language runtime 220 includes a garbage collector 222 and is implemented in software or hardware. When implemented in software, it is executed by the OS or in a memory management system on hardware. In the execution of application 250, during that time, language runtime 220 creates a new object on heap memory 212.
  • Garbage collector 222 performs memory collection (garbage collection) at the discretion of language runtime 220.
  • the zero GC communication mediating apparatus 230 includes at least one temporary object storage means 232 and at least one temporary object management means 234 in order to suppress the occurrence of GC during communication in the processing of the application 250. These include a plurality of temporary object storage means 232 and a plurality of temporary object management means 234. It is okay.
  • Temporary object storage means 232 holds a temporary object that is required in the execution of zero GC communication mediating apparatus 230 in order to avoid the generation of a temporary object every time. Temporary object storage means 232 only needs to be able to hold the object, so there are no restrictions on collection class, container class, hash table, singleton object 'pattern, cache, array, punore, inline cache, in object Means such as holding in the field can be used.
  • the temporary object management means 234 manages the temporary objects stored in the temporary object storage means 232.
  • the temporary object storage means 232 is searched to find an available temporary object, which is then reinitialized for reuse. Work to be performed, work to generate a new temporary object, and work to return a temporary object that becomes unnecessary after use to the temporary object storage means 232.
  • the implementation method of the temporary object management means 234 includes a method of providing an object and a component dedicated to this work, a method of describing processing directly in-line in the intermediary device, and an integration with the temporary object storage means 232.
  • a cache has a search function and a storage function. Note that the temporary object being used does not necessarily need to be removed from the temporary object management means 234 and may be stored in the temporary object management means 234 if there is no conflict with other users.
  • the number and correspondence of the temporary object management means 234 and the temporary object storage means 232 can be arbitrarily combined depending on the implementation. These temporary object storage means 232 and temporary object management means 234 provide a function of reusing temporary objects not only for mediation devices but also for applications that use mediation devices, and suppress GC in the entire application. it can.
  • the zero GC communication mediating apparatus 230 takes the embodiment as middleware, and operates in the middle layer of the language runtime 220 and the application 250. Since the embodiment of the present invention is not necessarily implemented as middleware, in another case, it is incorporated in the language runtime 220 as a part of the language function or as a part of the OS function. Incorporated or implemented.
  • the zero GC communication mediating device 230 is provided with a request type limiting unit 236, a transfer data number limiting unit 237, and a simultaneous and parallel use number limiting unit 238.
  • request type restriction means 236, transfer data number restriction means 237, and concurrent and parallel use restriction means 238 are respectively the request type, the type and number of data and objects transferred by the request, and the number of concurrent sessions. This is a limiting means to limit the number of uses to be within the expected range. Limit the intermediary requests by comparing each set limit value with the actual number of uses.
  • the request type limit value is the request type limit value setting means 240 ⁇ .
  • the transfer data number limit value is determined by the transfer data number limit value setting means 241. Each is set by the use number limit value setting means 242. Limit values are set by setting files, setting windows, or analysis of source code as described later.
  • FIG. 3 is a diagram for explaining how the temporary object storage means and the temporary object management means cooperate with the garbage collection means and the language runtime as a more preferred embodiment.
  • the garbage collector 322 is the power to provide the object storage means 332 and the temporary object management means 334, or the garbage collector 322 cooperates with the hour object storage means 332 and the temporary object management means 334. Works. This makes it possible to suppress GC more efficiently.
  • the language runtime 320 cooperates with the time object management means 334 when the temporary object is created, and is stored in the temporary object storage means 332 when the new temporary object is created. Operates to use objects.
  • the language runtime 320 does not generate a new temporary object, but searches the temporary object storage means 332 and reuses an object of the same type if it is already stored. If the heap memory 312 becomes tight and the garbage collector 322 runs out of GC, but the heap memory still runs short, the temporary object storage means 332 Some of the temporary objects can be selectively retrieved. A weak reference can be used for the implementation.
  • FIGS. 4, 8, and 9 taking as an example the client computer 110 that issues the request.
  • Fig. 4 shows a flowchart explaining the process of mediating a connection request to a service.
  • Fig. 8 shows an example of an application (client program).
  • Fig. 9 shows a service request.
  • 5 is a flowchart showing a process for managing a temporary object in the mediation process.
  • step 901 a request (step 901) is issued in the processing of the program shown in FIG.
  • the process in step 901 is a connection to a remote service, and a reference is obtained as a return value of this process.
  • This process creates session information for a series of remote sessions.
  • the remote service is requested by the processing of the next step 902 and step 903. If an argument is passed, the remote service performs some computation and returns a return value.
  • the session is then closed from step 904.
  • the service connection request process 400 as shown in FIG. 4 is started.
  • the concurrent concurrent usage limit means 238 first checks whether the concurrent concurrent usage (session count) exceeds the limit (step 401). If not, increase the number of simultaneous sessions (step 402), then generate an object as normal processing, and create session information, user information, user authentication as object processing A series of operations such as creating encrypted data, creating a reference identifier, creating a communication data buffer, creating a communication connection, etc. are performed (some are omitted because there are many). In this case, it is determined whether there is an object with the same type of session information (step 4).
  • Step 4 If there is an object, reinitialize the internal state of the object (Step 4).
  • Step 11 Reuse the object. If there is no object, create an object of the same type, initialize it, and use it (step 412). The same processing is performed for each object (Step 420 to Step 422, Step 430 to Step 432). Connect to the remote service (step 480) and return the caller reference as a result of the processing (step 495).
  • the temporary object management means when creating such data and information as an object, the temporary object management means is asked “Is there a session information object of the same type?” , (Step 410), the temporary object management means searches the temporary object storage means and returns it if there is any.
  • the connection process reinitializes and uses the session information object (step 411).
  • re-initialization is an operation to re-create the initial state of the object so that it matches the content of the request. Give the temporary object a reinitialization method and call it, or set the state using reflection. If there is no temporary object of the same type in the temporary object storage means, a new object is generated (step 412). Repeat this process for all necessary temporary objects.
  • the previously used temporary object is stored in the temporary object storage means. If the number of simultaneous sessions exceeds the limit value in the determination process in step 401, the mediation device 112 returns a failure to the client program 111 (step 490).
  • FIG. 9 is a flowchart showing a process for mediating the request issuance process (steps 902 and 903).
  • the request mediation process 1000 of FIG. 9 is called by the process of step 902 of the example program of FIG.
  • the request type called by the request type restriction means 236 confirms whether the type of the request is assumed (that does not exceed the limit) or not (step). 1001). This is a process necessary to ensure that the type of request does not swell unexpectedly and the number of types of temporary objects increases too much in an intermediary device that can dynamically expand the type of request, such as CORBA. is there.
  • the request stub is generated in advance. For systems such as CORBA requests, RMI, and HORB, this restriction is imposed at compile time, so it is not necessary at runtime (only a stub that accesses the specified method type is generated).
  • the transfer data number limiting means 237 confirms whether the argument type and number of the request are within the assumption (whether the limit number is exceeded) (step 1002).
  • the argument object types can be polymorphic and diverse. Again, accepting any type would increase the number of temporary objects, so you need to limit the number of type types.
  • processing for securing a data buffer for transmission (steps 1020 to 1022), processing for securing a data buffer for reception (steps 1030 to 1032), etc. are performed. These processes are also executed by generating objects or reusing objects.
  • step 1080 the request is transmitted to the remote computer and the result is received. If a temporary object is generated for the return value, it is reused in the same way, and the result is returned to the calling client 'program (step 1095). At the end of the session, the previously used temporary object must be stored in the temporary object storage means.
  • the temporary object is stored in the temporary object storage means while the processing of FIG. 4 or FIG. 9 is executed.
  • the program in Fig. 8 is executed from the second time onwards, enough temporary objects are stored in the temporary object storage means, and a reuse path is selected instead of new generation. To be done more.
  • the opportunity to create new temporary objects decreases, reaching a stable state where no temporary objects are generated. To do. This is the zero GC state.
  • the mediation device mediates the request and no GC is generated during the processing.
  • Application (client 'program') 111 and application (sano 'program) 111 using zero GC communication intermediary device 121 Also pay attention to object generation in its own processing, and perform explicit GC operation as necessary It is desirable. It is also desirable to record the memory usage and report if the memory usage exceeds a certain amount so that the next limit value can be set. The amount of heap memory that the system should have will be described later.
  • the memory usage increases for a while after the system starts to operate, but after the communication reaches the expected pattern, GC does not occur, and the zero GC state It becomes. Therefore, communication delay due to GC does not occur.
  • This makes it possible to develop a system that was impossible with conventional technology.
  • it is possible to implement an application that performs real-time communication processing in an object-oriented programming language equipped with a GC with high development efficiency and high safety.
  • the solution method according to the present invention is widespread, and there is an IJ point that can be implemented on a language runtime without real-time GC / parallel GC.
  • Non-Patent Document 1 if the object size increases and the pool size is insufficient, a power distribution application that takes a method of expanding the pool within the GC possible time
  • an intermediary device implemented by an object-oriented programming language such as, the GC possible time is unknown to the intermediary device, so the method addresses the problem of guaranteeing zero GC for all the expected communication patterns. I can't do it.
  • the intermediary device according to the present invention makes it possible to solve such a problem by imposing a limit on the opportunity of generating a temporary object by utilizing the characteristic that communication is regular.
  • the request is postponed by the request deferment means so that the start of request processing can be postponed within the next time range.
  • the configuration is as follows. As a result, it is possible to reduce the opportunity if the service cannot be used by rejecting the reception while ensuring the real-time property. Since the degree of real-time characteristics varies depending on the application, it becomes possible to cope with various real-time characteristics by making it possible to adjust the time range (time window) that can be postponed.
  • FIG. 14 is a flowchart for explaining mediation processing including postponement processing performed when a request exceeds a limit value.
  • the operation by the request deferral means will be described using the connection request processing to the service as an example.
  • the service connection request process 1600 is started in the request mediation process, it is checked whether or not the limit value is exceeded by a certain limiting means (step 1601). In this process, the number of simultaneous sessions is confirmed. If the number of simultaneous sessions exceeds the limit, wait for a certain time (within the time window) (step 1602), and determine whether the limit has been satisfied within the time window (step 1603). If it is not satisfied, that is, if it times out, a failure is returned (step 1606). If the limit value is satisfied by the termination of another session within the time window time, subsequent processing is performed (step 1604, step 1605, step 1607).
  • the mediation process including the request deferral process can be used in the service connection request process and the request mediation process.
  • the request deferral processing can be performed by a form in which the postponement is performed before the request mediation process and a form in which a queue is provided for each temporary object. Set the time window value in accordance with the real-time property required by the application or intermediary device.
  • FIG. 13 is a diagram for explaining another embodiment of the mediation device for zero garbage collection communication according to the present invention, and shows the position of the mediation device in the distributed application.
  • the intermediary device of this embodiment is configured to include stub generation means for generating stub code (also called a proxy, skeleton, or surrogate) that uses temporary object management means.
  • the stub code generation means is executed on the client side and the client side stub code 15 12 that is responsible for marshalling the API of the object, and the server side executes the unmarshalling of the communication contents to execute the server object.
  • Server-side stub code 1522 for the calling role is generated.
  • each of the generated stub codes (1512, 1522) calls the client-side mediating device 1513 and the server-side mediating device 1523 to perform communication.
  • the stub code may exist on both the client and server, or only one of them. There are forms that are generated at the time of development and forms that are dynamically generated at the time of execution.
  • Step 501 When the processing of the application is started, and then the initialization of the mediation device is started (step 501), the number of temporary objects within the range assumed in advance is generated and stored in the temporary object management means. (Step 502). At that time, if it is found that the amount of allocated heap memory is insufficient (step 503), an error is reported to the application (step 505), and measures can be taken at an early stage. To. If there is a sufficient amount of heap memory, the mediation device initialization is completed normally (step 504). Subsequently, the service connection request processing (step 510) shown in FIG. 6 is started.
  • the number of simultaneous sessions does not exceed the limit at the stage of connection request to the service or mediation processing to the service shown in Fig. 6, as described above. Increase the number of simultaneous sessions and execute the process (Steps 511 to 516) o Normally, temporary objects are newly generated as needed as explained by Fig.4 and Fig.9 In this case In FIG. 6, since the necessary temporary object already exists in the temporary object storage means, the service connection request processing 510 shown in FIG. 6 is started.
  • the session information object here is acquired and reused (step 513)
  • the user information object is acquired and reused (step 514)
  • the data buffer object is acquired and reused (step 514)
  • the processing such as 515) is performed by reusing the object stored in the temporary object storage means and processing without generating a new temporary object. This suppresses the occurrence of GC, and further ensures that no GC occurs.
  • the object pooling library for GC-less operation does not have a means to generate objects in advance and store them in the object pool, so there is a situation where heap memory is insufficient during execution. There is a case. You can expand the heap memory, but if the OS runs out of memory, the system will fail.
  • the intermediary device according to the present invention even if there is a mistake that the amount of memory allocated to the system is too small, there is an effect that is detected at the initial stage of execution.
  • FIG. 7 is a flowchart for explaining processing for obtaining information about a temporary object and determining a limit value.
  • the process shown in Fig. 7 is executed as a pre-process when the request mediation process service is started.
  • the limit value of the request type, the limit value of the type and number of data and objects transferred by the request, the limit value of the number of concurrent concurrent requests, and the type of temporary object to be pre-positioned And get limit parameters such as number.
  • Fig. 7 shows the pre-processing before starting the service connection request processing 400 (Fig. 4) and the request mediation processing 1000 (Fig. 9) at the time of development or at the start of operation.
  • Process 800 is performed.
  • this process 800 first, one or more of the application source code 'interface definition ⁇ service definition ⁇ program meta information' command line option specification, setting screen, configuration file 'compiled program is analyzed (step 801). From the information obtained as a result of the analysis, the request type R to be serviced remotely is extracted.
  • step 802 the type and number P of data and objects transferred by the request are extracted (step 803), and the number of users and the number of simultaneous sessions S are extracted (step 804).
  • the parameter of the limit value obtained by these becomes the limit value set in each limiting means (step 805).
  • the type and number of necessary temporary objects can be determined.
  • the maximum range of the temporary object to be pre-placed step 502 in FIG. 5
  • the maximum memory amount Mmax are determined (step 806). The meaning of these codes will be described later.
  • the mediation device may have to generate an immutable object.
  • the remote method 1201 takes an object of “ImmutableData” (1203) class as an argument.
  • the server-side mediating device 122 (Fig. 1) copies a copy of the object when calling the entity of the server 'method in the application (Sanno program) 121. It must be passed as an argument for processing. Making a copy of the object creates a new temporary object.
  • the server-side mediating device 122 synthesizes and passes this variable object MutableData (12004), which is a subclass of ImmutableData (1203), by executing the method 1202. Variable objects can be reused.
  • MutableData (12004 which is a subclass of ImmutableData (1203)
  • the object 1204 is a version obtained by removing final from the final field of the object 1203, and is synthesized at the time of development or execution. The same is true if the return value is an immutable object, as in method 1202. If a compatible subclass cannot be synthesized, such as the final String type, the application developer may be required to use a mutable object such as the StringBuffer type.
  • the basic type (eg int) is not an object, and the language does not use heap memory in the language.
  • many object-oriented programming languages provide wrapper objects (eg java. Lang. Integer) that allow basic types to be handled as objects for design flexibility. In some languages, wrapper objects are immutable objects. When it is necessary to transfer the wrapper object in the request, the basic type wrapper object is replaced with the basic type to avoid using heap memory.
  • wrapper objects are immutable objects.
  • the intermediary device As in the intermediary device according to the present invention, some types of requests are restricted by a plurality of restriction means, and communication that performs zero GC processing and zero GC processing are not performed. I sometimes used mixed communications! Whether or not the zero GC processing is performed can be switched for each session, for each request, for each communication partner, the importance of communication contents, or in the entire intermediary device. Good. With such a configuration, the mediation apparatus of the present invention can meet various application development requirements.
  • FIG. 12 is a flowchart for explaining a switching process between a mode in which zero GC processing is performed and a mode in which zero GC processing is not performed in request mediation processing.
  • the request mediation process It is possible to switch between operation modes and perform mediation processing in each operation mode.
  • the application sets a state variable indicating whether the zero GC processing is necessary for the mediation device in the request mediation processing.
  • the state variable is used to determine whether or not it is necessary to perform the zero GC process (step 1401). If necessary, the request intermediate is performed in the mode with the zero GC process as described above. (Step 1402). If not necessary, request mediation processing is performed in a mode in which zero GC processing is not performed (step 1403).
  • This request mediation processing in a mode in which zero GC processing is not performed is a request mediation processing by a conventional method.
  • the implementation that enables the switching of the operation mode is the simplest implementation in which the mode switching is performed in the entire intermediary device.
  • the operation mode can be switched for each session. Good.
  • the zero GC communication mediation device is provided with mode switching means for switching and mixing the mode in which the zero GC processing is performed and the mode in which the zero GC processing is not performed.
  • mode switching means for switching and mixing the mode in which the zero GC processing is performed and the mode in which the zero GC processing is not performed.
  • the method that does not generate a GC is a method (no, zero-zero GC system) that can maintain a zero GC state forever for any request pattern.
  • a hard solution that restricts the request by the restricting means may be too restrictive to use, so it is possible to use a less restrictive method (soft zero GC system). Even so!
  • T can be flexible.
  • That heap memory amount is the amount of memory required by the intermediary device to ensure that no GC occurs.
  • R is the set of request types
  • P is the amount of memory occupied by the maximum number of types and numbers of arguments and return values and transferred data and objects in a request
  • Tl the amount of memory that the mediation device itself requires in the initial state
  • S the maximum limit of the number of concurrent sessions
  • the amount of heap memory that the mediation device should have at the minimum is Mmax as shown in the formula in Fig. 15. expressed.
  • the usage amount of the heap memory can be reduced. Guaranteed not to exceed. Conversely, using the formula in Fig. 15, it is also possible to find the maximum number of sessions that the allocated heap memory capacity is allowed.
  • the maximum amount of heap memory is used only in the maximum load state in which all clients issue all requests at the same time. Many systems are unlikely to reach extreme loads, so it may not be necessary to have the maximum amount of heap memory. There is a trade-off between providing a memory close to the maximum heap memory amount to guarantee hard-end GC more strongly and reducing the heap memory amount by allowing the hard-end GC to be broken. It is also a preferable embodiment to grasp the trade-off relationship suitable for the system and to provide an appropriate amount of heap memory in accordance with the hard zero GC guarantee level that is sufficient in specification. [0123]
  • the mediation apparatus according to the present invention can also be implemented using nodeware.
  • the intermediary device greatly improves real-time performance in a request mediation device implemented in a programming language equipped with a GC or a request mediation device implemented in hardware equipped with memory management. In order to improve, it can be widely used in industrial equipment, robots, communication devices, space equipment, automobiles, etc. that communicate on the network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Abstract

　ガベージコレクションを備えるオブジェクト指向プログラミング言語により実装されるリクエスト仲介装置が提供される。ネットワーク上の複数のコンピュータ間でサービスのリクエストを仲介する装置において、ガベージコレクションの発生により通信が中断し、リアルタイム性が損なわれることを解消するため、このリクエスト仲介装置は、リクエスト毎に一時的・反復的に生成される一時オブジェクトを再使用する手段と通信パターンを制限する手段を備え、これらの手段により、ガベージコレクションの発生を抑止し、リアルタイム性を改善する。  

Description

明 細 書
ゼロガベージコレクション通信仲介装置
技術分野
[0001] この発明は、ガベージコレクションを備えるプログラミング言語による実行環境、もし くは使用済みメモリ管理手段を備えるハードウェアで実行されるコンピュータ間の遠 隔リクエストのために、リアルタイム性を向上させてリクエスト仲介を行うリクエスト仲介 装置に関するものであり、更に詳細には、ワークメモリ不足時に動作が開始されるガ ページコレクションの発生を抑制して、ネットワーク上の複数のコンピュータ間で動作 する分散 ·並列リアルタイム ·アプリケーションプログラムによるシステム構築に利用さ れる通信ミドルウェア、プログラミング言語、オペレーティングシステム、通信仲介ハー ドウエアの処理におけるリアルタイム性を向上させる仲介装置に関するものである。 背景技術
[0002] ネットワークもしくはバス上の複数のコンピュータ間で動作する分散 Z並列アプリケ ーシヨン 'プログラム（以下、アプリケーションと略称する）の処理においては、通信を 行ってリモート（遠隔）のコンピュータ上のオブジェクトやサービスをリクエストする（リモ ートメソッドを呼び出す)。多くの並列アプリケーションにおけるリクエスト処理は分散 アプリケーションと共通性があるため、以下では「分散」と総称する。この場合の分散 アプリケーションにおける通信処理を人手で設計することは煩雑で相互運用性が限 定されるため、リクエスト仲介の機能を提供するリクエスト仲介装置を利用することが 一般的である。
[0003] 本発明が対象とするリクエスト仲介装置は、分散オブジェクト、並列オブジェクト、 W ebサービス、エージェントシステム、 P2Pシステム、音声'映像配信装置等、分散処理 及び並列処理に関する高度な通信機能を有する装置である。装置の形態としては、 ミドルウェア、並列 Z分散オペレーティングシステム（以下、 OSと略称する）、並列 Z 分散言語、ライブラリが多ぐソフトウェアあるいはハードウェアによって実現される（図 1)。通信ミドルウェアの例としては、 WEBサービス、 CORBA、 RMI、 HORB、 P2P システムなどがある。本発明ではこれらを「リクエスト仲介装置」あるいは「仲介装置」と 総称する。
[0004] 本明細書において、リクエストという用語は、リモート手続き呼び出し (Remote Pr ocedure Call)、リモートメソッド呼び出し（Remote Method Invocation)、リモ 一トサービス呼び出し（Remote Service Invocation)などを意味する。リクエスト 仲介装置は、リクエストをサービスするアプリケーションの処理そのものではなぐクラ イアント ·コンピュータが発行したリクエストをサーバ，コンピュータに仲介し、その返答 をまたクライアント 'コンピュータに伝える役割を負っている。例えば、分散オブジェクト や Webサービスの場合は、アプリケーション中に記述される遠隔コンピュータ上のセ ンサ一の計測値の読み出しのプログラムは、「value = ref. getSensor()」のよう な記述によるものとなる（図 8参照)。この一行のプログラム片が仲介装置を呼び出し、 ネットワークを介する比較的複雑な通信処理を自動的に行わせる。
[0005] リクエスト仲介の通信処理を行わず、データをパケットにより送るだけの TCPや UD Pレベルのネットワーク ·ライブラリ、分散アプリケーション自体の構成法は含まな 、。 なお、本発明においてコンピュータとは、パソコン、サーバだけではなぐ組込み機器 内の小さなマイコン、同一システム内の複数の通信するコンポーネント等を広範に意 味するものとする。
[0006] 近年、機械と機械の間をネットワークで結び高度なシステムを構築する様態の分散 リアルタイム ·アプリケーションの開発が進んでいる。例えば、ネットワークで同期をとり ながら集団で動作する人型ロボット、家庭内にリアルタイムのビデオストリームをサー ビスする情報家電機器、道路と交信しながら自動運転する自動車などが典型的な例 である。そのような分散リアルタイム 'アプリケーションのための仲介装置は、リクエスト の仲介処理の際に一定の応答時間や定期的な周期を持つ通信が確実に行われると いったリアルタイム性を保証しなければならない。また、リアルタイムといわないまでも 、高速な応答が必要な分散アプリケーションも多い。
[0007] しかし、 Java (登録商標)言語などの現代的なプログラミング言語で開発された仲介 装置は、以下に述べる理由で応答時間や周期性を保証することができないという問 題があるため、リアルタイム性が必要な分散リアルタイム ·アプリケーションでは C言語 や C + +言語といった昔ながらのプログラミング言語が使用されることが多い。 [0008] C言語や C+ +言語のプログラミング言語を使用する場合、プログラマはメモリの割 り当て、メモリ使用後のメモリ返却といった操作を行う処理についても、プログラム処理 の中で明示的に記述する必要がある。プログラムの作成の中で、例えばメモリの使用 後に返却する指示を記述することを忘れるとメモリリークが起き、メモリ不足となってァ プリケーシヨンが異常終了する場合がある。作成したプログラムを検証する場合に、そ のプログラムの処理の中でのメモリリークは発見が難しぐ開発効率やシステムの安 全性を大きく損なう要因である。
[0009] そのため、 Java (登録商標）言語や C #言語と 、つた現代的なプログラミング言語の 実行環境では、ガベージコレクション (GC)と呼ばれるメモリ管理方式を採用している
[0010] ガベージコレクション（以下、 GCと略称する）では、「ガベージコレクタ」が定期的に 全オブジェクトをチェックし、オブジェクトが「どの参照型変数からも参照されて 、な ヽ 」場合にはオブジェクトを削除する。これにより、当該オブジェクトが使用していたメモ リ（ヒープメモリ）が開放され、再び利用可能となる。このような現代的なプログラミング 言語により作成されたプログラム処理では、オブジェクトを好きなときに生成するだけ でよい。
[0011] オブジェクトはヒープメモリ上に生成される。ヒープメモリは限られた量しかなぐヒー プメモリが不足すると、プログラム処理が異常終了する場合があるが、 GCは使われな くなつたオブジェクトが占有するメモリを、自動的に回収して、ヒープメモリに返却する ので、メモリは再利用される。このようにして、プログラマをメモリ管理力 解放すること によって、 Java (登録商標）言語を利用するプログラマの生産性は、 C言語もしくは C + +言語を用いた場合に対して大幅に向上した。
[0012] しかし、この GCの処理は、言語ランライム（例えば、 Java仮想マシン）の裁量で発生 し、プログラムの実行を中断して行われる。このため、分散リアルタイム 'アプリケーシ ヨンの処理においては、予測できない GCが発生する場合があり、通信処理を実行し ている際に、予測不可能な通信の中断が発生する場合があり、これが重大な事故の 原因となる場合がある。
[0013] 既存のオブジェクト指向プログラミング言語により実装された仲介装置製品である C ORBA、 J2EE、 Webサービス製品などの Javaによる仲介装置においては、リクエスト (リモートメソッド呼び出し）のたびにかなりの量の一時オブジェクトが生成されるため、 GCが頻繁に発生する。ここで、一時オブジェクトとは、リクエスト仲介処理に伴って仲 介装置内で生成される全ての種類のオブジェクトを指している。具体的には、リモート のサービスを提供するサーノ 'オブジェクト、通信バッファのように大きなデータから、 通信相手のホスト名やユーザ名、セッション識別子、リクエスト番号といった些細なデ ータまで、ヒープメモリ中に格納される全てのオブジェクトを含む。これらは文字列ォ ブジェクト、構造体的なオブジェクト、配列オブジェクトなどを用いて実装されており、 セッションのたび、あるいは個々のリクエストのたびに生成され、使用後に GCによつ て回収される。一時オブジェクトの生成の際にメモリが足りないと、 GCが発生するの で、通信が中断されることになる。一時的ではないオブジェクトとは、セッションやリク ェストの寿命を越えて存続するオブジェクトで、仲介装置内では例えば起動中のサ 一ノ^オブジェ外を記録する表の場合、仲介装置の開始と共に生成され、終了まで 存続する。
[0014] 例えば、次表は、幾つかの Java仲介装置において、 1回のリクエスト（リモートメソッ ド呼び出し)の間に生成される一時オブジェクト数と使用される一時メモリ量を調査し た結果である。
[表 1]
Figure imgf000006_0001
[0015] 更に、次表は、リクエスト 2000回あたりの GCの発生数を調査した結果である。この ように、多くの GCが発生していることが分かる。
[表 2]
Figure imgf000006_0002
[0016] このように、リクエストにおける一時オブジェクトの生成は、リクエスト中に GCを発生 させ、通信中断を引き起こす場合があるので、 GC付きの実行環境で実行されるプロ グラミング言語で開発されたリクエスト仲介装置がリアルタイム性の必要なアプリケー シヨンで利用されな力つた大きな要因である。ハードウェアによって仲介装置を実装 する場合も、使用済みメモリを管理する手段、即ちハードウェアによる GCが必要であ り、同様の問題を含んでいる。
[0017] これに対して、 GCに起因するこの種の問題の解決を試みた幾つかの発明が提案さ れている。例えば、特許文献 13においては、「reCyCle()メソッド」を実装することにより クラスを再利用可能にして、オブジェクトが再利用可能かどうかを GCのプロセスが決 定できるようにすることが提案されている。これは、オブジェクトを再利用して、ォブジ ェタトの生成を防ぐためのよい機構である力 もし、たまたま、ガベージコレクタがリサ イタル可能なオブジェクトを見つけられな力つた場合、メモリ領域全体に跨る GCが発 生してしまう。したがって、この特許文献 13の発明は、オブジェクト生成のコストを削 減するにはよ 、が、 GCによる通信の中断を防ぐことはできな 、。
[0018] 特許文献 10においては、メソッド呼び出しから固定 ·定数オブジェクトの生成を取り 除く方法の発明が提案されている。この特許文献 10の発明によれば、反復的なプロ セスにおけるメモリの使いすぎの問題を部分的には解決できる。しかし、ほとんどのリ タエスト仲介装置においては、リクエストは多様な型を扱う動的なプロセスであり、その プロセスにおける大部分の一時オブジェクトは、固定されているわけでも、定数でもな い。
[0019] 具体例で説明すると、ビデオ等のストリーミング配信システムは、アプリケーションに 対して QoS (Quality of Service：品質の確保された通信）を提供している。 QoS 仲介装置や OSのドライバは、 CPU時間やネットワーク上でのバンド幅を優先的に割 り当てることにより通信品質を保証する。メモリの割り当てに関しては、 OSが各ストリー ムの通信バッファ用のメモリ量を QoSレベルに応じて割り当てる。この技術の適用範 囲は通信データ用のバッファに限定されたものであり、リクエストの間に生成される多 くの小さ 、一時オブジェクトを扱うことは行われて!/、な!/、。
[0020] また、幾つかの組織からリアルタイム Javaの規格が提唱されている。リアルタイム Jav aは、多くの複雑な戦略によってこの問題に対抗している。例えば、ィモータルメモリ（ 恒久メモリ）、スコープドメモリ（範囲ィ匕メモリ）やリアルタイムスレッドなどがあげられる。 GCは、リアルタイム Javaのプラットフォームでも起こるため、オブジェクトを生成'廃棄 する限りは、リクエスト仲介処理にぉ 、ては GCによる通信中断の問題に突き当たる。 また、普及の遅れて 、るリアルタイム Javaではな 、通常の Java製品を使 ヽた 、場合も 多い。
[0021] リアルタイム GCと並行 GCの手法は、本発明が取り組んでいる課題を解決する別の よい手段である。リアルタイム GCは、シングル CPU上で GCの時間を細分化すること により割り込み応答性能を改善する。並行 GCは、マルチ CPUシステム上でひとつの CPUを GC処理に割り当てることにより、他 CPUが GCにより実行を中断することがな いようにする。
[0022] 非特許文献 1においては、組込み Javaアプリケーションにおいて GCによりリアルタ ィム性が欠如する問題に対処するため、オブジェクト 'プーリングを中心とする設計ガ イドライン、 GCレス AWT (Abstract Windowing Toolkit)描画ライブラリ、 GCレ ス UDP (User Datagram Protocol)パケット 'サーバを開発している。そこでは、 オブジェクトはプーリングし再利用する、データの受け渡しにオブジェクトでは値型を 使用する、 Stringなどの不変オブジェクトではなく配列などの可変オブジェクトを使 用する、といった GC発生を予防する基本的な手法が提案されている。
[0023] この提案は本発明の先行技術となるものであるが、基本的な描画ライブラリや UDP パケットの受信といった基本的なレベルに留まっており、分散オブジェクトや Webサ 一ビスと 、つた高度な通信処理に関する課題解決の方法には言及して 、な 、。サー ビスへのリクエストを仲介するリクエスト仲介装置は複雑であるため、単にオブジェクト をプーリングするのみでは課題は解決されな!、。
[0024] この明細書において参照として挙げられている特許文献 1〜16のその他の発明は 、コンピュータシステムにおけるメモリ管理手段もしくはリアルタイム処理に関係するも のである。しかし、それらは、ここで説明する GC問題を解決することを意図したもので はない。先行技術の動向を鑑みて、われわれはこの問題に対して、改善された方法 を供給する価値は十分あると考える。
特許文献 1：特開昭 63 - 93055号公報 特許文献 2：特開 2001— 188704号公報
特許文献 3：特開 2001 - 202284号公報
特許文献 4 :米国特許第 6678697号明細書
特許文献 5：米国特許第 5950231号明細書
特許文献 6：米国特許第 6272674号明細書
特許文献 7：米国特許第 6055492号明細書
特許文献 8：米国特許第 6754796号明細書
特許文献 9 :米国特許第 6751790号明細書
特許文献 10 :米国特許第 6701520号明細書
特許文献 11：米国特許第 6430564号明細書
特許文献 12：米国特許第 6748555号明細書
特許文献 13 :米国特許第 6138127号明細書
特許文献 14 :米国特許第 6611898号明細書
特許文献 15 :米国特許第 6529948号明細書
特許文献 16 :米国特許第 6381735号明細書
非特許文献 1 :組込み Java実用コンソーシアム， Embedded Technology 2004講演報 告組込み Javaリアルタイム性の確保と適用ガイドライン〜 GUI/ネットワークの GCレス ライブラリの実装〜講演資料 http://www.ejpc.Org/et2004/et2004.htmlhttp://www. ejpc.org/et2004/et2004p2.pdf
非特許文献 2 : ReaH:imePlatform SIG, Realtime CORBA, white paper, Object Manag ement Group, Dec. 199b, Editor: Judy McGoogan, Lucent Technologies.
非特許文献 3 : Ray Clark, E.Douglas Jensen, Doug Wells, Andy Wellings, The distrib uted Real— timeSpecification for Java: A Status Report, Embedded Systems Conferen ce, March2002. JSR 50: Distributed Real-Time Specification
発明の開示
発明が解決しょうとする課題
ところで、 GCを備えるオブジェクト指向のプログラミング言語を用いて開発された分 散オブジェクトや Webサービス等の仲介装置では、反復的なリクエスト仲介処理中に 生成される多くの一時オブジェクトのために GCが発生する。 GCが発生するとプログ ラムの処理が中断され、その間、通信も中断する。
[0026] オブジェクトの生成を行わなければ GCは発生しない。 GCが発生しなければ通信 の中断も起きない。しかし、一般的には通信の内容は多様であり、内容次第でメモリ の使用量は大きく異なる。また、応用によってはアプリケーションが改良されるたびに リクエストの種類や転送されるデータの種類が増えてゆく。単なる TCPのパケットライ ブラリのような低レベルのものでは GCの抑制は容易である力 分散オブジェクトや W ebサービスのような通信内容に意味がある仲介装置では様々なオブジェクトが生成 されるため困難である。
[0027] 本発明は、このような問題を解決するためになされたものであり、本発明の第 1の課 題は、一定時間内の応答通信や周期的な通信が必要な分散リアルタイム 'アプリケ ーシヨンのためのリクエスト仲介装置において、設計時に想定した範囲内のあらゆる 通信パターンに対しリクエスト仲介処理中に通信中断が発生しな 、ことを保証できる リクエスト仲介装置を提供することある。このようなリクエスト仲介装置のシステム構成 をハードゼロ GCシステムと称する。
[0028] 本発明の第 2の課題は、設計時に想定した範囲を逸脱する通信パターンを有する アプリケーション、あるいは、設計時に明確な範囲を想定することができないアプリケ ーシヨンに対しても、通信中断を減少させるリクエスト仲介装置を提供することにある。 このようなリクエスト仲介装置によると、リクエスト仲介装置における処理の特性だけで はなぐアプリケーションにおける処理の特性によって通信の中断が発生しない、ある いは、アプリケーションの特性にもよる力 通信の中断力 Sいくらか起きても良いアプリ ケーシヨンに対するリクエスト仲介の処理を行うことができるリクエスト仲介装置がこれ に該当する。このようなリクエスト仲介装置のシステム構成をソフトゼロ GCシステムと 称する。
[0029] 本発明の第 3の課題は、 1のリクエスト仲介装置において、通信中断を抑制するモ ードと、通信中断の抑制機能を使用しないモードでの動作可能とした仲介装置を提 供することである。これは、ひとつのアプリケーション内でも常時リアルタイム性が求め られるとは限らないためである。ひとつの分散アプリケーションがリアルタイム性の必 要な通信と必要ない通信を混在して使用する場合、計算資源や開発コストが倍増す るが、その計算資源や開発コストの増加を軽減することできる仲介装置が提供される
[0030] したがって、上記のような課題を解決する本発明の目的は、ガベージコレクションを 備えるオブジェクト指向プログラミング言語の実行環境で実行されるコンピュータ間の 遠隔リクエスト仲介のために、ガベージコレクションの発生を抑制し、またはガベージ コレクションを発生しないようにして、リアルタイム性を向上させてリクエスト仲介を行う ゼロガベージコレクション通信のための仲介装置を提供することにある。 課題を解決するための手段
[0031] 上記の目的を達成するため、本発明は、第 1の態様として、本発明によるゼロガべ ージコレクション通信のための仲介装置は、ガベージコレクション機能を備えるォブジ ェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲 介処理をガベージコレクションを抑制して行う仲介装置であって、前記仲介処理のた めに一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持す る一時オブジェクト格納手段と、前記使用済みの一時オブジェクトを再利用のために 初期化する一時オブジェクト管理手段と、リクエストの種類の制限値を設定するリクェ スト種類制限値設定手段と、前記リクエストの種類の制限値によりリクエストの種類を 制限するリクエスト種類制限手段と、転送データ数の制限値を設定する転送データ 数制限値設定手段と、前記転送データ数の制限値によりリクエストによって転送され るデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段と、同 時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、前記同時 並行使用数の制限値によりリクエストの同時並行使用数を制限する同時並行使用数 制限手段と、を具備することを特徴とするものである。
[0032] このような態様の仲介装置においては、アプリケーションに特有な通信パターンの 局所性を利用すると共に、人為的に通信パターンを制限することにより第 1の課題を 解決するものとして ヽる。
[0033] アプリケーションでは、分野によっては、あるコンピュータがもう一方のコンピュータ に通信セッションを開設し通信を始めると、同じようなリクエストを繰り返す傾向を示す 場合がある。特に、機械と機械との間の通信、例えば、ロボット内部や自動車内部の コンポーネント間の通信などの組込み機器間の通信は、センサーのデータの取得と V、つた少な 、種類のリクエストの単調な繰り返しが多!、。
[0034] このような通信には、所定のパターンがあるという特性を利用すると、メモリ使用の最 適化が可能となる。つまり、同様のリクエストが繰り返されるのであれば、毎回のリクェ ストのたびに必要な一時オブジェクトを生成するのではなぐ通信前あるいは最初の 一回目に生成した一時オブジェクトを使用後に破棄せずに次回以後も使い回すこと により、 GCの発生を抑制することができる。以後これを「ゼロ GC」と呼ぶ。
[0035] アプリケーションによって通信パターンは大きく異なる。転送されるオブジェクトの数 が多すぎる状態の通信、予想より多いクライアント 'コンピュータから同時に通信が起 きるといった予想外の通信が発生すると、一時オブジェクトの生成数が増えすぎてヒ ープメモリが枯渴する。したがって、アプリケーション毎に想定される通信パターンの 範囲を決めることにより、一時オブジェクトが多く生成されないようにする。
[0036] 例えば、制限する通信パターンの範囲としては、通信を受け付けることができるか（ 同時セッション数が多すぎないか）、どの種類のリクエストの通信を行うか、通信で転 送されるデータの種類と数、を制限すれば十分である。これにより、本発明を適用可 能なアプリケーションの分野も同時に制限を受ける力 多くのアプリケーションでは、 その中の通信処理に規則性があるため、これで十分な場合も多い。
[0037] このように、一時オブジェクトの生成数を抑制して、ヒープメモリが枯渴することがな いようにすることにより、 GCの発生を抑制し、さらには GCを発生させないようにする 方法は、 1)想定内のあらゆるリクエストのパターンに対して、永久にゼロ GC状態を保 つことが可能な解決手段 (ノヽードゼロ GCシステム）とする力、あるいは、アプリケーショ ンによってはハードな解決手段では制限が強すぎて使用できない場合もあるため、 2 )より制限の緩い方法 (ソフトゼロ GCシステム）とするかのどちらかである。
[0038] そこで、本発明による仲介装置（「ゼロ GC通信仲介装置」）は、第 1の態様として、 G C機構を有するオブジェクト指向プログラミング言語で実装される通信の仲介を行うシ ステムにおいては、システムに備えられた処理要素（各処理手段）により、次のような 処理を行う。 [0039] 一時オブジェクトの生成が必要な場合は、オブジェクト管理手段によって一時ォブ ジェタト格納手段を検索し、同じ型で使用済みの一時オブジェクトが格納されていれ ば、それを取り出して再利用し、使用後は一時オブジェクト格納手段に再度格納する 。また、当該一時オブジェクトと同じ型のオブジェクトが、一時オブジェクト格納手段内 に存在しない場合は、一時オブジェクト管理手段は新しいオブジェクトを生成し、使 用に供する。新規に生成された一時オブジェクトは、使用後に一時オブジェクト格納 手段内に格納される。ハードゼロ GCシステムとする場合には、メモリ使用量はシステ ムに与えられたヒープメモリ割当量を超えることができない。
[0040] そこで、想定外の通信パターンによる一時オブジェクトの生成数の増えすぎを防ぐ ため、リクエスト種類制限手段により、リクエストの種類を制限し、データ転送数制限 手段により、引数あるいは返値として転送されるデータ及びオブジェクトの種類と数を 制限し、更に、同時並行使用数制限手段により、同時に発生するセッションの数を制 限する。これらの制限手段による制限は、後述するように、実行時に行う形態と、開発 時に行う形態がある。実行時に制限されたリクエストは、処理が延期されるか、クライ アントに例外あるいはエラーとして通知される。これらの制限値の設定は、リクエストの 種類の制限値は、リクエスト種類制限値設定手段により、転送データ数の制限値は、 転送データ数制限値設定手段により、リクエストの同時並行使用数の制限値は、同 時並行使用数制限値設定手段により、それぞれ設定する。
[0041] これにより、本発明による仲介装置においては、一時オブジェクトの生成の機会は 管理され、想定された通信パターンの範囲内であれば、リクエストの仲介処理をいくら 行っても GCに起因する通信の中断が発生しない。また、想定外の通信パターンは排 除される。このため、ハードゼロ GC状態となり、リアルタイム性の高い通信が可能とな る。
[0042] また、本発明は、第 2の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、更に、前記リクエスト種類制限手段によ り、リクエストの種類が制限され、前記転送データ数制限手段により、リクエストによつ て転送されるデータ及びオブジェクトの種類及び個数が制限され、または、前記同時 並行使用数制限手段により、リクエストの同時並行使用数が制限される。リクエストを 開始できな 、場合にぉ 、て、リクエスト処理の開始をタイムウィンドウ時間の範囲内で 延期するリクエスト延期手段を備えるように構成される。
[0043] これによると、リクエスト延期手段を備え、前述したような制限手段により、リクエスト を受付できな 、場合にぉ 、て、リクエスト処理の開始を次の時間の範囲内で延期で きるように構成される。リクエスト延期手段によってリクエストを延期することにより、リア ルタイム性を確保しつつ受付拒否でサービスが利用できない機会を減少させることが できる。リアルタイム性の度合いはアプリケーションによって異なるため、延期可能な 時間範囲（タイムウィンドウ）を調節可能とすることによって、多様なリアルタイム性に 対応することができるよう〖こなる。
[0044] また、本発明は、第 3の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、更に、前記一時オブジェクト管理手段 を使用するスタブコードを生成するスタブ生成手段を具備する構成とされても良い。
[0045] このようなスタブコード生成手段を備えることにより、スタブコード（プロキシ、スケルト ン、サロゲートとも呼ばれる）を使用して遠隔サービスを実現する仲介装置において は、一時オブジェクト管理手段を用いて、 GCが発生することがないコードを生成する ことで、 GCが発生することを抑制する。
[0046] また、本発明は、第 4の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、更に、一時オブジェクトを必要とするリク ェスト仲介処理が開始される前に、一時オブジェクトが生成されて、前記一時ォブジ ェクト格納手段内に事前配置されるように構成される。
[0047] これにより、仲介装置においては、一時オブジェクト管理手段力 一時オブジェクト 格納手段に一時オブジェクトを事前配置することにより、ランタイムのオブジェクトの配 置コストを削減することができるようになる。一時オブジェクト格納手段に一時オブジェ タトを事前配置する方法をとることによって、事前、あるいは最初のリクエストの間に、 全ての一時オブジェクトが生成'格納されてしまい、それ以降のリクエストにおいて一 時オブジェクトの生成はなくなるため、リクエスト仲介処理中の GCは発生しない。
[0048] また、本発明は、第 5の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、同時並行使用数制限手段が、クライア ントの数もしくは同時に使用されるセッションの数に基づいて同時並行使用数制限値 を決定し、一時オブジェクト格納手段に事前配置する一時オブジェクトの最大数を決 定するように構成される。
[0049] これにより、仲介装置において、ゼロ GC動作するために必要とされる一時オブジェ タトの数を、通信相手の数、すなわち、同時に使用するユーザの数や同時に通信す る相手の数によって決定することができ、複数のユーザや複数の通信相手のある環 境に対応可能となる。ヒープメモリの量としては、 1セッションで使用されるメモリ量と同 時セッション数との積が最低限必要となる。
[0050] また、本発明は、第 6の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、リクエスト種類制限手段により制限する リクエストの種類の制限値と、転送データ数制限手段により制限するリクエストによつ て転送されるデータ及びオブジェクトの種類及び個数の制限値と、同時並行使用数 制限手段により制限するリクエストの同時並行使用数の制限値と、前記一時オブジェ タト格納手段に事前配置する一時オブジェクトの種類及び個数との制限値のパラメ ータは、ソースコード、インターフェース定義、サービス定義、プログラムメタ情報、コ マンド行のオプション指定、設定画面、設定ファイル、コンパイルされたプログラムの 中の少なくとも一つを解析することによって得るように構成される。
[0051] このような構成により、使用される一時オブジェクトについての情報により、それぞれ の制限手段における各制限値を決定することができ、更に、一時オブジェクト格納手 段にどの型のオブジェクトをどれだけの数だけ事前配置するかを決定することができ る。使用される一時オブジェクトについての情報は、ソースコード、インターフェース定 義、サービス定義、プログラムメタ情報、コマンド行のオプション指定、設定画面、設 定ファイルもしくはコンパイルされたプログラムを開発時あるいは実行初期に解析する ことにより得られる。リクエストが送られるサ一ノ^オブジェクト、リクエストが受け渡しす るパラメータで使用する一時オブジェクト、仲介装置内で使用する一時オブジェクトの 型と数に関する情報が得られる。
[0052] また、本発明は、第 7の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、この仲介装置において、一時オブジェクト管理手段は、ある一時 オブジェクトが不変オブジェクトであった場合に、その一時オブジェクトを可変ォブジ ェタトに置き換えるように構成される。このような構成により、本発明による仲介装置は 、不変オブジェクトの代わりとなる可変オブジェクトを提供して、当該可変オブジェクト を再利用できるようにする。
[0053] オブジェクト指向プログラミング言語ではオブジェクトの可変性にっ 、て 2種類の分 類がある。ひとつは一度設定したフィールドの内容を変更可能な可変 (mutable)ォ ブジェクト、もう一つは一度設定したフィールドの内容を変更不可能な不変 (immuta ble)オブジェクトである。 Javaの不変オブジェクトの例としては Stringオブジェクトや I ntegerオブジェクトがある。 Stringオブジェクトの可変版として StringBufferォブジ ェタトが提供されている。不変オブジェクトは状態が変更できない為、再利用不可能 である。このため、仲介装置を設計する際にゼロ GCにするならば、不変オブジェクト を使用しな 、ことが有効である。
[0054] ところが、アプリケーションがリクエストの引数あるいは返値に不変オブジェクトを指 定したため、仲介装置が不変オブジェクトを生成しなければならないことがある。その 生成を防ぐため、本発明による仲介装置においては、不変オブジェクトの代わりとな る可変オブジェクトを提供するため、一時オブジェクト管理手段が、ある一時オブジェ タトが不変オブジェクトであった場合に、その一時オブジェクトを可変オブジェクトに置 き換えるようにして、当該可変オブジェクトを再利用する。
[0055] また、本発明は、第 8の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置は、更に、ガベージコレクション抑制処理を行うモードと、ガベージコ レクシヨン抑制処理を行なわないモードを切り替える動作モード切替手段が備えられ 、動作モード切替手段が、それぞれの動作モードに応じて一時オブジェクト管理手段 の使用'不使用と、リクエスト種類制限値設定手段に設定する制限値と、転送データ 数制限値設定手段に設定する制限値と、同時並行使用数制限値設定手段に設定 する制限値の各設定値を設定するように構成される。
[0056] このような構成により、本発明による仲介装置は、動作モード切替手段によって、ガ ページコレクション抑制処理を行うモードと、ガベージコレクション抑制処理を行なわ ないモードを切り替えることができる。アプリケーションによっては、同一アプリケーショ ン内でゼロ GC処理を行わない通信を行う必要がある場合があり、ひとつのアプリケ ーシヨンがゼロ GC通信仲介装置と通常の仲介装置の両方を備えることは無駄が多 い。そのために、ゼロ GC通信仲介装置はゼロ GC通信を行うモードと、ゼロ GC処理 を行わな!/、モードを切り替えて、アプリケーションに適切な動作モードを選択できるよ うにする。
[0057] ところで、本発明による仲介装置においては、リクエストの種類を限定するなどいく つかの制限手段を設けて、例えば、通信の仲介処理において GCが発生しないこと を保証するが、アプリケーションによっては、全ての制限手段により制限を課すとシス テムが実現できないようになる場合がある。このため、必要に応じて、 3つの制限手段 の全てではなぐ 1つまたは 2つの制限手段を利用するだけとして、より広い範囲の応 用をカバーできるようにする。
[0058] したがって、本発明は、第 9の態様として、本発明によるゼロガベージコレクション通 信のための仲介装置力 ガベージコレクション機能を備えるオブジェクト指向プロダラ ミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージ コレクションを抑制して行う仲介装置であって、前記仲介処理のために使われたォブ ジェタトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、 前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段とを備 え、前記リクエスト制限手段は、リクエストの種類を制限するリクエスト種類制限手段、 リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転 送データ数制限手段、またはリクエストの同時並行使用数を制限する同時並行使用 数制限手段のいずれかであるように構成する。このような構成により、より広い範囲の アプリケーションをカバーするができる。
[0059] また、本発明は、第 10の態様として、本発明によるゼロガベージコレクション通信の ための仲介装置力 ガベージコレクション機能を備えるオブジェクト指向プロダラミン グ言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレ クシヨンを抑制して行う仲介装置であって、前記仲介処理のために使われたオブジェ タトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、前記 使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手 段と、前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段とを備え、 前記リクエスト制限手段は、リクエストの種類を制限するリクエスト種類制限手段、リク ェストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送デ ータ数制限手段、またはリクエストの同時並行使用数を制限する同時並行使用数制 限手段のいずれか 2つであるように構成する。このような構成により、より広い範囲の アプリケーションをカバーするができる。
[0060] 本発明は、第 11の態様として、本発明によるゼロガベージコレクション通信のため の仲介装置が、当該仲介装置におけるメモリ使用量を適切に管理できるように、メモ リ割り当て方法が提供される。このための本発明によるメモリ割り当て方法は、ガベー ジコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコ ンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介 装置におけるメモリの割り当て方法であって、前記仲介装置が備えるべき最大のヒー プメモリ量は、仲介装置自身が初期状態で必要とするメモリ量に加えて、 1のリクエス トにお ヽて引数及び返値として転送されるデータの最大メモリ量をリクエスト種類制限 値に含まれるリクエストの種類毎に足し合わせたメモリの量にセッション毎に仲介装置 自身が必要とするメモリの量を加えた量に、同時並行使用数の制限値をかけ算して 得られるメモリ量を割り当てる。
[0061] これにより、本発明による仲介装置に備えるべき最大のヒープメモリ量は計算式によ り求めることができ、仲介装置におけるメモリ使用量を適切に管理できるようになる。 本発明による仲介装置は、実装にソフトウェアを用いるだけではなぐハードウェアに より実装されてもよい。
発明の効果
[0062] 本発明の仲介装置によれば、メモリ不足時に動作が開始されるガベージコレクショ ンの発生を抑制して、ネットワーク上の複数のコンピュータ間で動作する分散リアルタ ィム 'アプリケーション構築に利用される通信ミドルウェア、プログラミング言語、ォペレ 一ティングシステムの処理におけるリアルタイム性を向上させることができる。
図面の簡単な説明 [0063] [図 1]本発明によるゼロガベージコレクション通信のための仲介装置の位置付けを説 明する図である。
[図 2]本発明によるゼロガベージコレクション通信のための仲介装置のシステム構成 を説明する図である。
[図 3]—時オブジェクト格納手段と一時オブジェクト管理手段がガベージコレクション 手段と言語ランタイムと協調する様子を表す図である。
[図 4]サービスへの接続要求を仲介する処理を説明するフローチャートである。
[図 5]事前配置を伴うシステムにおいて一時オブジェクトの事前配置と再利用を行うス テツプを説明する第 1のフローチャートである。
[図 6]事前配置を伴うシステムにおいて一時オブジェクトの事前配置と再利用を行うス テツプを説明する第 2のフローチャートである。
[図 7]—時オブジェクトについての情報を得て制限値を決定する処理を説明するフロ 一チャートである。
[図 8]アプリケーション (クライアント 'プログラム）の一例を示す図である。
[図 9]サービス要求の仲介処理における一時オブジェクトを管理する処理を示すフロ 一チャートである。
[図 10]不変オブジェクトの使用例を説明する図である。
[図 11]制限を緩和したリクエスト仲介処理のステップを説明するフローチャートである
[図 12]リクエスト仲介処理においてゼロ GC処理を行うモードと行わないモードの切り 替え処理を説明するフローチャートである。
[図 13]スタブコードとスタブコード生成手段の位置付けを表した図である。
[図 14]リクエストが制限値を越えた場合に行う延期処理を含む仲介処理を説明するフ ローチャートである。
[図 15]使用する最大ヒープメモリ量を算出する式を示す図である。
符号の説明
[0064] 110 クライアント 'コンピュータ
111 アプリケーション（クライアント 'プログラム） 112 クライアント側仲介装置
120 サーノ 'コンピュータ
121 アプリケーション（サーノ 'プログラム)
122 サーバ側仲介装置
130 通信媒体
200 コンピュータ
212 ヒープメモリ
220 言語ランタイム
222 ガベージコレクタ
230 ゼロ GC通信仲介装置
232 一時オブジェクト格納手段
234 一時オブジェクト管理手段
235 リクエスト延期手段
236 リクエスト種類制限手段
237 転送データ数制限手段
238 同時並行使用数制限手段
239 動作モード切替手段
240 リクエスト種類制限値設定手段
241 転送データ数制限値設定手段
242 同時並行使用数制限値設定手段
250 アプリケーション
312 ヒープメモリ
320 言語ランタイム
322 ガベージコレクタ
330 ゼロ GC通信仲介装置
332 一時オブジェクト格納手段
334 一時オブジェクト管理手段
340 アプリケーション 1510 クライアント 'コンピュータ
1511 アプリケーション（クライアント 'プログラム）
1512 クライアント側スタブコード
1513 クライアント側仲介装置
1520 サーノ 'コンピュータ
1521 アプリケーション（サーノ 'プログラム）
1522 サーバ側スタブコード
1523 サーバ側仲介装置
1530 通信媒体
発明を実施するための最良の形態
[0065] 以下に、本発明の具体的な実施の形態を図を用いて説明する。理解を容易なもの とするため説明には、 Java (登録商標)プログラミング言語を用いる。しかし、本発明 による仲介装置は、 C #言語等 GCを備える他のオブジェクト指向プログラミング言語 にも適用可能である。
[0066] 本発明は、主に、通信の中断を避けなければならない分散リアルタイム 'アプリケー シヨン、通信の中断が望ましくない非リアルタイムの分散アプリケーション、処理速度 や応答速度の向上のために GCを避けた 、分散アプリケーションにお 、て使用される ミドルウェア、通信ライブラリ、言語、もしくは OSに適用される。
[0067] 図 1は、本発明によるゼロガベージコレクション通信のための仲介装置の位置付け を説明する図である。分散アプリケーション中の仲介装置の位置づけを示している。 図 1に示すように、クライアント 'コンピュータ 110とサーバ'コンピュータ 120とが通信 媒体 130により結合され、この 2つのコンピュータの間でデータ通信が行われる。通 信は 2台あるいはそれ以上の数のコンピュータの間で、あるいは、 1台のコンピュータ の中の複数の通信要素の間で行われる。通信の情報そのものは通信媒体 130を介 して伝達される。通信媒体 130としては、例えば、複数台のコンピュータの間の通信 にはネットワークが利用され、 1台のコンピュータの中の複数の通信要素の間の通信 にはデータノ スなどが利用される。
[0068] ここでは説明のために、 2台のコンピュータを便宜的にリクエストを発行する側のクラ イアント.コンピュータ 110とリクエストを受け付けサービスする側のサーバ 'コンビユー タ 120に分ける。アプリケーションは、クライアント側で動作するアプリケーション (クラ イアント ·プログラム） 111とサーバ側で動作するアプリケーション（サーバ ·プログラム） 121から構成される。アプリケーションの中で行う通信処理は、クライアント側仲介装 置 112とサーバ側仲介装置 122によって仲介される。例えば、 CORBAにおいては、 クライアント側仲介装置 112は、クライアント側スタブおよびクライアント側通信ランタイ ム、サーバ側仲介装置 122は、サーバ側スタブおよびサーバ側ランタイム力も構成さ れ、アプリケーション (クライアント 'プログラム） 111には、サーバ側スタブを呼び出す アプリケーションが、アプリケーション（サーノ 'プログラム） 121にはサービスを実行す るサーノ 'オブジェクトが含まれる。 Webサービスでもビデオサーバでも同様の構成 をとる。
[0069] 図 2は、本発明によるゼロガベージコレクション通信のための仲介装置のシステム構 成を説明する図である。ゼロ GC通信仲介装置を搭載するひとつのコンピュータ上で の構成例を示している。図 2において、 200はサーバ側またはクライアント側の 1つの コンピュータを示しており、 220はゼロ GC通信仲介装置 230によって使用される言語 ランタイムである。
[0070] 言語ランタイム 220の例としては、「Java仮想マシン」、「. NET CLR」、「GNU M onoランタイム」などが挙げられる。中間コード実行方式、コンパイル時ネイティブコー ド変換方式、実行時ネイティブコード変換方式を問わない。言語ランタイム 220は、ガ ページコレクタ 222を含んでおり、ソフトウェアまたはハードウェアで実装される。ソフト ウェアで実装される場合は OSにより実行され、またはハードウェア上でのメモリ管理 システムの中で実行される。アプリケーション 250の実行において、その間、言語ラン タイム 220は、新しいオブジェクトをヒープメモリ 212上に生成する。ガーべッジコレク タ 222は、言語ランタイム 220の裁量においてメモリの回収作業 (ゴミ回収）を行う。
[0071] ゼロ GC通信仲介装置 230は、アプリケーション 250の処理における通信中の GC の発生を抑制するため、少なくとも一つの一時オブジェクト格納手段 232と、少なくと も一つの一時オブジェクト管理手段 234を備える。これらは、複数個の一時オブジェ タト格納手段 232と、複数個の一時オブジェクト管理手段 234が備えられる構成であ つても良い。
[0072] 一時オブジェクト格納手段 232は、一時オブジェクトが毎回生成されることを避ける ため、ゼロ GC通信仲介装置 230の実行において必要とされる一時オブジェクトを保 持する。一時オブジェクト格納手段 232の実装としては、オブジェクトが保持できれば よいので、特に制限はなぐコレクションクラス、コンテナクラス、ハッシュテーブル、シ ングルトンオブジェクト 'パターン、キャッシュ、配列、プーノレ、インラインキャッシュ、ォ ブジェクト中のフィールドでの保持といった手段が利用できる。
[0073] 一時オブジェクト管理手段 234は、一時オブジェクト格納手段 232で格納される一 時オブジェクトの管理を行う。一時オブジェクトの管理処理においては、仲介処理に おいて一時オブジェクトが必要になった際に、一時オブジェクト格納手段 232を検索 して利用可能な一時オブジェクトを見つけ出す作業、それを再初期化して再利用に 供する作業、新規の一時オブジェクトを生成する作業、使用後に不要となった一時ォ ブジェクトを一時オブジェクト格納手段 232に戻す作業を行う。
[0074] 一時オブジェクト管理手段 234の実装方法としては、この作業を専用に行うォブジ ェクトやコンポーネントを設ける方法、仲介装置内にインラインで直接処理を記述する 方法、一時オブジェクト格納手段 232と一体ィ匕させる方法 (例えば、キャッシュは検索 機能や格納機能を備える）が利用できる。なお、使用中の一時オブジェクトは必ずし も一時オブジェクト管理手段 234から外される必要はなぐ他の使用者と競合が起き なければ一時オブジェクト管理手段 234に格納されたままになっていてもよい。
[0075] 一時オブジェクト管理手段 234と一時オブジェクト格納手段 232の数と対応付けは 実装の都合により任意の組み合わせが可能である。これら一時オブジェクト格納手段 232と一時オブジェクト管理手段 234は、仲介装置だけではなぐ仲介装置を使用す るアプリケーションに対しても一時オブジェクト再利用の機能を提供し、アプリケーショ ン全体で GCを抑制するようにできる。
[0076] ゼロ GC通信仲介装置 230は、図 2に示すようなシステム構成では、ミドルウェアとし ての実施形態を取り、言語ランタイム 220とアプリケーション 250の中間層で動作する 。本発明の実施の形態はミドルウェアとしての実施とは限らないため、別の場合には 、言語機能の一部として言語ランタイム 220内に組み込まれたり、 OS機能の一部に 組み込まれたりして実施される。
[0077] Webサービスの場合は XMLのパースを行い、パース結果を表すオブジェクトツリー を構築する。ツリー内の各要素オブジェクトも一時オブジェクト管理手段を用いて再 利用する。
[0078] ゼロ GC通信仲介装置 230には、リクエスト種類制限手段 236、転送データ数制限 手段 237、同時並行使用数制限手段 238が設けられる。これらのリクエスト種類制限 手段 236、転送データ数制限手段 237、同時並行使用数制限手段 238は、それぞ れに、リクエストの種類、リクエストによって転送されるデータ及びオブジェクトの種類 と数、同時並行セッションの使用数が、想定した範囲内に入っているように制限する 制限手段である。設定した各制限値と実際の使用数との比較によって仲介するリクェ ストを制限する。リクエストの種類の制限値は、リクエスト種類制限値設定手段 240〖こ より、転送データ数の制限値は、転送データ数制限値設定手段 241により、リクエスト の同時並行使用数の制限値は、同時並行使用数制限値設定手段 242により、それ ぞれ設定される。制限値の設定は設定ファイル、設定ウィンドウ、あるいは、後述する ように、ソースコードの解析等により行われる。
[0079] 図 3は、より好ましい実施の例として、一時オブジェクト格納手段と一時オブジェクト 管理手段がガベージコレクション手段と言語ランタイムと協調する様子を説明する図 である。ガベージコレクション手段であるガベージコレクタ 322がー時オブジェクト格 納手段 332と一時オブジェクト管理手段 334とを提供する力、あるいはガベージコレ クタ 322がー時オブジェクト格納手段 332および一時オブジェクト管理手段 334と協 調して動作する。これにより、より効率の良い GCの抑制が可能となる。
[0080] 図 3に示されるように、一時オブジェクトの生成の際に、言語ランタイム 320がー時 オブジェクト管理手段 334と協働し、新規の一時オブジェクト生成時に一時オブジェ タト格納手段 332に格納されたオブジェクトを利用するように動作する。一時オブジェ タト生成の際に、言語ランタイム 320は新規の一時オブジェクトを生成するのではなく 、一時オブジェクト格納手段 332を検索し、同じ型のオブジェクトが既に格納されてい る場合はそれを再利用する。ガベージコレクタ 322はヒープメモリ 312が逼迫し、 GC を行っても、なおヒープメモリが欠乏する場合には、一時オブジェクト格納手段 332中 の一時オブジェクトのいくつかを選択的に回収することができる。その実装には弱参 照（ウィークリファレンス）を用いることができる。
[0081] 次に、図 4、図 8、図 9を用いて、リクエストを発行する側のクライアント 'コンピュータ 110を例に取り、リクエスト仲介処理の手順について説明する。サーバ側のサーバ' コンピュータ 120についても同様である。図 4には、サービスへの接続要求を仲介す る処理を説明するフローチャートを示しており、図 8には、アプリケーション (クライアン ト.プログラム）の一例を示しており、図 9には、サービス要求の仲介処理における一 時オブジェクトを管理する処理を示すフローチャートを示している。
[0082] クライアント 'コンピュータ 110において、アプリケーション（クライアント 'プログラム） 1 11力 図 8に示すプログラムの処理の中で、リクエスト（ステップ 901)を発行するとす る。ステップ 901の処理は、遠隔サービスへの接続であり、この処理の返値としてリフ アレンスを得る。この処理で、一連の遠隔セッションのためのセッション情報が作成さ れる。次のステップ 902およびステップ 903の処理により、遠隔サービスをリクエストす る。引数を渡すと遠隔サービスが何らかの計算を行い、返値を返す。そして、ステップ 904の処理〖こより、セッションを閉じる。
[0083] 遠隔サービスへの接続処理 (ステップ 901)では、図 4に示すようなサービスへの接 続要求処理 400が開始される。サービスへの接続要求処理 400が開始されると、こ の中で、まず、同時並行使用数制限手段 238によって同時並行使用数 (セッション数 )が制限値を越えていないかが確認され (ステップ 401)、越えていない場合は同時 セッション数を増加させた後（ステップ 402)、正常時の処理として、オブジェクトを生 成して、オブジェクトの処理として、セッション情報の作成、ユーザ情報の作成、ユー ザ認証用暗号データの作成、リファレンス識別子の作成、通信データバッファの作成 、通信用コネクションの作成などの一連の作業を行う（数が多いのでいくつかは略す） 。この場合に、同型のセッション情報のオブジェクトはあるか否かを判定し (ステップ 4
10)、オブジェクトがある場合は、オブジェクト内部状態の再初期化を行い (ステップ 4
11)、当該オブジェクトを再利用し、また、オブジェクトがない場合には、同型のォブ ジェタトを生成し、初期化して利用する (ステップ 412)。同様の処理を各オブジェクト について行い（ステップ 420〜ステップ 422、ステップ 430〜ステップ 432)、その後、 遠隔サービスへの接続を行って (ステップ 480)、処理の結果として、呼び出し側ヘレ ファレンスを返す処理を行う（ステップ 495)。
[0084] すなわち、このオブジェクトの処理では、図 4に示すように、それらのデータや情報 をオブジェクトとして作成する際には、一時オブジェクト管理手段に「同型のセッション 情報オブジェクトはあるか？」を問 、合せ (ステップ 410)、一時オブジェクト管理手段 は一時オブジェクト格納手段を検索し、あればそれを返す。接続処理は当該セッショ ン情報オブジェクトを再初期化して使用する (ステップ 411)。ここで再初期化は、リク ェストの内容に合うようにオブジェクトの初期状態を再び作る操作である。一時ォブジ ェタトに再初期化用メソッドを持たせて、それを呼び出すか、リフレクションを用いて状 態の設定を行う。同型の一時オブジェクトが一時オブジェクト格納手段になければ、 新規にオブジェクトを生成する (ステップ 412)。このような処理を、必要な全ての一時 オブジェクトに対して繰り返し行う。セッション終了時の処理（図 8のステップ 904)に は、前に使用した一時オブジェクトを一時オブジェクト格納手段に格納する。また、ス テツプ 401の判定処理において、同時セッション数が制限値を越える場合は、仲介 装置 112は、クライアント ·プログラム 111に失敗を返す (ステップ 490)。
[0085] ここでの図 4のフローチャートによる処理および図 8に示すプログラム例は、説明の ためにあるひとつの実施例について述べたものであり、本発明を異なる一時オブジェ タトの構成を有する仲介装置に適用する場合には、図 4の処理では、異なるフローチ ヤートとなる。しかし、通信パターンを限定しつつ一時オブジェクトを再利用することで 、 GCを抑制すると 、う本発明の本質は変わることがな 、。
[0086] 図 9は、リクエスト発行の処理 (ステップ 902、ステップ 903)の仲介を行う処理を示 すフローチャートである。図 8のプログラム例のステップ 902の処理により、図 9のリク ェスト仲介処理 1000が呼び出される。この仲介処理 1000が開始されると、リクエスト 種類制限手段 236によって呼び出されたリクエストの種別は想定されたもの (制限数 を超えないもの）である力、想定されていないものかを確認する（ステップ 1001)。こ れは、 CORBAのように動的にリクエストの種類を拡張可能な仲介装置においては、 リクエストの種類が想定外に膨らんで一時オブジェクトの種類が増えすぎな 、ように するために必要な処理である。なお、予めリクエストのスタブを生成しておくような静 的 CORBA要求、 RMIや HORBのようなシステムでは、コンパイル時にこの制限が 行われるため、実行時には不要である（規定されたメソッドの種類をアクセスするスタ ブしか生成されない)。
[0087] 次に、同様に転送データ数制限手段 237によってリクエストの引数の型や数につい ても、想定内に収まって 、るか (制限数を超えな 、か）を確認する（ステップ 1002)。 例えば、オブジェクトの配列を引数としてリクエストを行う場合、配列の要素数が想定 以上に多いと一時オブジェクトの数が増えすぎてしまうため、それは避けなければな らない。引数のオブジェクトの型はポリモーフイズムで多様であり得る。その場合も、あ らゆる型を受け入れると一時オブジェクトの数が増えすぎてしまうため、型の種類の数 を制限する必要がある。映像配信システムのようにオブジェクトの転送を行わな ヽシ ステムでは、一部を省略可能である。それらの確認が終了した後、送信用のデータバ ッファを確保する処理 (ステップ 1020〜ステップ 1022)、受信用データバッファの確 保する処理 (ステップ 1030〜ステップ 1032)などを行う。これらの処理についてもォ ブジェクトを生成し、またはオブジェクトの再利用により処理が実行される。
[0088] これらも一時オブジェクト管理手段と一時オブジェクト格納手段を用いて行うが、実 際に必要な一時オブジェクトの種別はシステムによって異なる。このようなオブジェク トによる処理を行い、ステップ 1080において遠隔のコンピュータにリクエストを伝達し 、その結果を受け取る。返値に対しても一時オブジェクトが発生する場合は、同様に 再利用を行い、呼び出したクライアント 'プログラムに結果を返す (ステップ 1095)。セ ッシヨン終了時には、先に使用した一時オブジェクトは一時オブジェクト格納手段に 格納されなければならな 、。
[0089] 図 8のプログラムが初めて実行される際には、図 4もしくは図 9の処理が実行される 中で、一時オブジェクト格納手段中に一時オブジェクトが格納されて 、な 、場合は、 一時オブジェクトの新規生成が頻繁に発生する力 図 8のプログラムが 2回目以降に 実行される際には、一時オブジェクト格納手段に十分な一時オブジェクトが格納され ており、新規生成ではなく再利用の経路が選択されることが多くなる。このように処理 が継続されて、分散アプリケーションの処理が進行するにしたがって、一時オブジェ タトを新規生成する機会は減り、一時オブジェクトの生成が発生しない安定状態に達 する。これがゼロ GC状態である。
[0090] このようにしてゼロ GC状態になると、これで、仲介装置がリクエストを仲介して 、る 処理中に GCが発生することはなくなる。ゼロ GC通信仲介装置を使用するアプリケー シヨン（クライアント 'プログラム） 111およびアプリケーション（サーノ 'プログラム） 121 自身の処理においてもオブジェクト生成には気を配り、また、必要に応じて明示的な GC操作を行うことが望ましい。また、メモリ使用量の記録をとつて、一定メモリ使用量 を超えた場合には報告をし、次回の制限値の設定に役立てることが望ましい。システ ムが備えるべきヒープメモリ量にっ 、ては後述する。
[0091] このような構成による仲介装置においては、システムが動作を始めてしばらくの間は メモリ使用量は増加するが、通信が予想されたパターンに達した後では GCは発生し なくなり、ゼロ GC状態となる。したがって、 GCに起因する通信遅延は発生しなくなる 。このため、従来の技術では不可能であったようなシステム開発が可能になる。例え ば、開発効率が高く安全性の高い GCを備えるオブジェクト指向プログラミング言語で リアルタイム性の必要な通信処理を行うアプリケーションを実装することが可能となる 。リアルタイム GCや並列 GCによる課題解決手法と比較して、本発明による解決手法 は普及して 、るリアルタイム GC ·並列 GCを備えな 、言語ランタイム上で実施可能と なる禾 IJ点がある。
[0092] また、非特許文献 1の GCレス動作用オブジェクトプーリングライブラリでは、ォブジ ェタトが増えてプールの大きさが不足する場合には、プールを GC可能時間内に拡大 する手法をとる力 分散アプリケーションなどのオブジェクト指向プログラミング言語に より実装される仲介装置においては、 GC可能時間は仲介装置にとって不明の事で あるため、その手法では想定内のあらゆる通信パターンに対しゼロ GCを保証すると いう課題に対処することはできない。本発明による仲介装置では、通信には規則性が あるという特性を利用して一時オブジェクト生成の機会に制限を課すことにより、この ような課題を解決することができるようにして 、る。
[0093] 次に、本発明による仲介装置の別の実施例について説明する。前述したように、そ れぞれの制限手段によって、リクエストを受付できない場合、リクエスト処理の開始を 次の時間の範囲内で延期できるように、リクエスト延期手段によってリクエストを延期 する構成とする。これにより、リアルタイム性を確保しつつ受付拒否でサービスが利用 できな 、機会を減少させることができるものとなる。リアルタイム性の度合いはアプリケ ーシヨンによって異なるため、延期可能な時間範囲 (タイムウィンドウ）を調節可能とす ることによって、多様なリアルタイム性に対応することができるようになる。
[0094] 図 14は、リクエストが制限値を越えた場合に行う延期処理を含む仲介処理を説明 するフローチャートである。図 14を参照して、サービスへの接続要求処理を例にとつ てリクエスト延期手段による動作を説明する。リクエストの仲介処理の中で、サービス への接続要求処理 1600が開始されると、ある制限手段により制限値を越えていない かが確認される（ステップ 1601)。この処理では、同時セッション数を確認している。 同時セッション数が制限数を超える場合には、一定時間（タイムウィンドウ内で)待つ て (ステップ 1602)、タイムウィンドウ内において制限値が満たされたかを判断する（ ステップ 1603)。満たされなカゝつた場合、即ち、タイムアウトした場合には、失敗を返 す (ステップ 1606)。タイムウィンドウ時間の内に他のセッションが終了することにより 、制限値が満たされた場合には後続の処理を行う（ステップ 1604、ステップ 1605、ス テツプ 1607)。
[0095] このように、リクエスト延期処理を含む仲介処理は、サービスへの接続要求処理に おいても各リクエストの仲介処理においても使用が可能である。この場合、リクエスト 仲介処理の前段階で延期を行う形態と、それぞれ一時オブジェクト毎に待ち行列を 設けて延期を行う形態により、リクエスト延期処理を行うことができる。タイムウィンドウ 値の設定はアプリケーションまたは仲介装置が必要とするリアルタイム性に応じて事 jに行う o
[0096] このようにして、リクエスト仲介処理を行う際に、制限手段によってリクエストを受付で きない場合においては、リクエスト処理の開始をアプリケーションが必要とするリアル タイム性を満たす時間の範囲内で延期することにより、アプリケーション毎に必要なリ アルタイム性を確保しつつ受付拒否でサービスが利用できない機会を減少させること ができる。
[0097] 次に、図 13は、本発明によるゼロガベージコレクション通信のための仲介装置の別 の実施例を説明する図であり、分散アプリケーション中の仲介装置の位置づけを示し ている。この実施例の仲介装置は、一時オブジェクト管理手段を使用するスタブコー ド (プロキシ、スケルトン、サロゲートとも呼ばれる）を生成するスタブ生成手段を具備 する構成である。図 13において、スタブコード生成手段は、クライアント側で実行され サーノ 'オブジェクトの APIをマーシャリングする役割のクライアント側スタブコード 15 12と、サーバ側で実行され通信内容をアンマーシヤリングしサ一ノ^オブジェクトを呼 び出す役割のサーバ側スタブコード 1522を生成する。
[0098] スタブコード生成に際して、スタブコード内で一時オブジェクトを生成する従来の方 式ではなぐ一時オブジェクト管理手段を用いて一時オブジェクトを再利用し、 GCが 発生することがないコードを生成することにより、通信の中断を防止する。生成された それぞれのスタブコード（1512、 1522)は、それぞれクライアント側仲介装置 1513 及びサーバ側仲介装置 1523を呼び出して通信を行う。スタブコードはクライアントと サーバの両方に存在する場合も一方のみの場合もあるし、開発時に生成する形態と 実行時に動的に生成する形態がある。
[0099] 図 5および図 6のフローチャートを参照して、本発明による仲介装置の別の実施例 について説明する。アプリケーションの処理が開始されて、続いて、仲介装置の初期 化が開始されると (ステップ 501)、予め想定される範囲内の数の一時オブジェクトを 事前に生成して一時オブジェクト管理手段に格納する (ステップ 502)。その際に、も し、割り当てられたヒープメモリの量が不足することが判明した場合 (ステップ 503)に は、アプリケーションに異常を報告し (ステップ 505)、早い段階において対策を施す ことができるようにする。十分な量のヒープメモリ量がある場合には、正常に仲介装置 の初期化が終了する（ステップ 504)。続いて、図 6に示すサービスへの接続要求処 理 (ステップ 510)を開始する。
[0100] 図 5に示すような処理を行った後に、図 6に示すサービスへの接続要求やサービス への仲介処理を行う段階では、前述したように、同時セッション数が制限数を超えな い場合に、同時セッション数を増加し、処理を実行する (ステップ 511〜ステップ 516 ) o通常では、図 4および図 9により説明したように一時オブジェクトは必要に応じて新 規生成される力 この場合において、必要な一時オブジェクトは既に一時オブジェク ト格納手段に存在して 、るため、図 6に示すサービスへの接続要求処理 510が開始 されても、ここでのセッション情報オブジェクトを取得し再利用すること (ステップ 513) ,ユーザ情報オブジェクトを取得し再利用すること (ステップ 514) ,データバッファォ ブジェクトを取得し再利用すること (ステップ 515)等の処理は、一時オブジェクト格納 手段に格納されて ヽるオブジェクトが再利用されて処理が進められ、新規な一時ォブ ジェタトは生成することなぐ処理が行われる。これにより、 GCが発生することが抑制 され、更には、 GCが発生しないことが保証される。
[0101] このように、システムを起動した時に一時オブジェクトを生成して、事前に一時ォブ ジェタト格納手段に格納しておくことで、実行時はそれらを生成する必要がなくなり、 実行時の速度が改善する効果があるものとなる。
[0102] 従来技術の非特許文献 1の GCレス動作用オブジェクトプーリングライブラリでは、 事前にオブジェクト生成を行 、オブジェクト ·プールに格納する手段を持たな 、ため、 実行時にヒープメモリが欠乏する事態が発生する場合がある。ヒープメモリを拡張す ることはできるが、 OSのメモリが足りなくなるとシステムはエラーとならざるを得ない。こ れに対して、本発明による仲介装置によれば、万一システムに割り当てられたメモリ 量が少なすぎるといったミスがあった場合も、実行の初期に発見される効果がある。
[0103] 次に、本発明による仲介装置における制限手段の制限値を設定する処理について 説明する。図 7は、一時オブジェクトについての情報を得て制限値を決定する処理を 説明するフローチャートである。図 7に示す処理は、リクエスト仲介処理のサービスを 開始する場合に前処理として実行される。この処理の実行により、リクエストの種類の 制限値、リクエストによって転送されるデータ及びオブジェクトの種類と数の制限値、 リクエストの同時並行使用数の制限値、及び、事前配置すべき一時オブジェクトの種 類と数などの制限値のパラメータを得る。
[0104] 開発時にぉ 、て、または、運用開始時にぉ 、て、サービスへの接続要求処理 400 ( 図 4)およびリクエスト仲介処理 1000 (図 9)の開始前の前処理として、図 7に示す処 理 800を行う。この処理 800では、まず、アプリケーションのソースコード 'インタフエ一 ス定義 ·サービス定義 ·プログラムメタ情報 'コマンド行のオプション指定、設定画面、 設定ファイル 'コンパイルされたプログラムのうち一つ以上を解析する（ステップ 801) 。解析の結果、得られた情報から、リモートでサービスすべきリクエストの種類 Rを抽 出し (ステップ 802)、リクエストによって転送されるデータ及びオブジェクトの種類と数 Pを抽出し (ステップ 803)、使用ユーザ数や同時セッション数 Sを抽出する (ステップ 804)。これらにより得られた制限値のパラメータがそれぞれの制限手段に設定される 制限値となる (ステップ 805)。これらに仲介装置が、各セッションのために内部で使 用する一時オブジェクト T1 ·Τ2を加味すると、必要となる一時オブジェクトの種類と数 が判明する。更に、事前配置（図 5のステップ 502)すべき一時オブジェクトの最大の 範囲と最大メモリ量 Mmaxが決定される (ステップ 806)。これらの符号の意味は後述 する。
[0105] このようにして、アプリケーションがどの種類の一時オブジェクトを、どれくらいの数 だけ使用するか、そして、何台のクライアントやいくつの通信相手に対して同時にサ 一ビスを提供すればよいかを知ることにより、十分なメモリを割り当てることができる。 このため、メモリ使用量がシステムに与えられたメモリ割当量を超えてしまい、 GCが 発生する状態になることを防ぐことができる。
[0106] さて、アプリケーションが不変オブジェクトを生成した場合、前述したように、不変ォ ブジェクトは状態が変更できないため、このオブジェクトは再利用不可能である。した がって、仲介装置を設計する際にゼロ GCシステムとするには、不変オブジェクトを使 用しな!/ヽ処理とすることが有効である。
[0107] ところが、アプリケーションによっては、アプリケーションがリクエストの引数あるいは 返値に不変オブジェクトを指定したため、仲介装置が不変オブジェクトを生成しなけ ればならないことがある。例えば、図 10に示すプログラム例においては、リモートなメ ソッド 1201は、引数として「ImmutableData」（1203)クラスのオブジェクトを取る。
[0108] このアプリケーションのプログラムの実行において、サーバ側仲介装置 122 (図 1) は、アプリケーション（サ一ノ^プログラム） 121内にあるサーバ'メソッドの実体を呼び 出す際に、当該オブジェクトのコピーを引数として渡して処理させなければならない。 そのオブジェクトのコピーの作成が新規の一時オブジェクトの生成になる。そのォブ ジェタトの新規生成を防ぐため、サーバ側仲介装置 122は、メソッド 1202の実行によ り、 ImmutableData (1203)のサブクラスである可変オブジェクト MutableData (12 04)を合成して渡すことにより、この可変オブジェクトは再利用することができる。 [0109] オブジェクト 1203が不変オブジェクトであることは、 finalフィールドの存在により検 出される。オブジェクト 1204は、オブジェクト 1203の finalフィールドから finalを除去 したバージョンであり、開発時あるいは実行時に合成される。これは、メソッド 1202に あるように、返値が不変オブジェクトである場合も同様である。 finalクラスである Strin g型のように互換性のあるサブクラスが合成できな ヽ場合は、アプリケーション開発者 は StringBuffer型のような可変オブジェクトを使用するよう要請される場合がある。
[0110] また、基本型（例えば int)がオブジェクトではな 、言語では、基本型はヒープメモリ を使用しない。一方で、多くのオブジェクト指向プログラミング言語において、設計の 柔軟性のために、基本型をオブジェクトとして扱うことを可能とするラッパーォブジェク ト（例えば java. lang. Integer)を提供している。いくつかの言語では、ラッパーォブ ジェタトは不変オブジェクトである。リクエスト中でラッパ一オブジェクトを転送する必要 がある際は、ヒープメモリの使用を避けるために、基本型のラッパ一オブジェクトを基 本型に置き換える操作を行う。アプリケーション開発者は、リクエストにおいてラッパ一 オブジェクトではなぐ基本型を使用するよう要請される場合がある。
[0111] 不変オブジェクトの可変オブジェクトへの置換は、オブジェクトの再使用を可能にし 、 GCの発生を抑制することに寄与する。
[0112] また、本発明を利用していない既存の仲介装置のソースコードを読み込んで、一時 オブジェクトの検出、一時オブジェクトを再利用するコードへの変換、不変オブジェク トの可変オブジェクトへの変換等、本発明の適用を行う変換システムは有用である。
[0113] さて、アプリケーションによっては、本発明による仲介装置のように、複数の制限手 段によりいくつかの種類のリクエストが制限されて、ゼロ GC処理を行う通信と、ゼロ G C処理を行わな ヽ通信を混在させて使用した!/ヽことがある。ゼロ GC処理を行うかどう かは、セッション毎、リクエスト毎、通信相手毎、通信内容の重要性により、あるいは仲 介装置全体で切り替えることができるように、本発明の仲介装置が構成されてもよい。 このような構成により、本発明の仲介装置は、多様なアプリケーション開発の要求に 対応できるものとなる。
[0114] 図 12は、リクエスト仲介処理においてゼロ GC処理を行うモードと行わないモードの 切り替え処理を説明するフローチャートである。リクエスト仲介処理において、このよう に動作モードの切り換えを行 、、それぞれの動作モードでの仲介処理を行うことがで きる。この場合には、アプリケーションは、仲介装置が当該リクエスト仲介処理に際し てゼロ GC処理が必要力否かを示す状態変数を設定しておく。リクエスト仲介処理が 始まると、その状態変数を用いてゼロ GC処理が必要である力否かを判定し (ステップ 1401)、必要である場合は、前述したようなゼロ GC処理付きのモードでリクエスト仲 介処理を行う（ステップ 1402)。必要でない場合には、ゼロ GC処理を行わないモー ドでのリクエスト仲介処理を行う（ステップ 1403)。この、ゼロ GC処理を行わないモー ドでのリクエスト仲介処理は、従来手法によるリクエスト仲介処理である。
[0115] このような動作モードの切り換えを可能にする実装は、仲介装置全体でモードの切 り替えを行うことが最も簡易な実装である力 セッション毎に動作モードを切り換えら れるようにしてもよい。セッション毎に異なるモードが混在する処理を行う場合は、ゼロ GC処理を行わな 、モードがヒープメモリを消費するため、ヒープメモリをそれぞれの モードに割り当てて、リアルタイム GCや並行 GCを使用してヒープメモリの飽和を防ぐ ことが望ましい。
[0116] 本発明による仲介装置においては、ゼロ GC通信仲介装置がゼロ GC処理を行うモ ードとゼロ GC処理を行わないモードとを切り替えて混在させるモード切替手段を備え ることにより、同一アプリケーション内で、ゼロ GC処理によりリアルタイム性の高い通 信と、（制限手段によって)サービスが拒否さることがない通信とを切り替えて使用す ることが可能となる。このような構成にすると、ひとつのアプリケーションにおいて、ゼロ GC通信仲介装置と通常の仲介装置の両方を備える必要がなくなるため、計算資源 や開発コストが軽減される効果がある。
[0117] このように、リクエスト仲介処理において、 GCを発生させない方法は、あらゆるリクェ ストのパターンに対しても永久にゼロ GC状態を保つことが可能な方法 (ノ、ードゼロ G Cシステム）である力、あるいは、アプリケーションによっては、制限手段によりリクエス トが制限されるハードな解決手段では制限が強すぎて使用できない場合もあるため、 より制限の緩 、方法 (ソフトゼロ GCシステム）とするような構成であってもよ!/、。
[0118] 図 11に示すリクエスト仲介処理においては、いくつかの制限手段を外し、引数の型 と数のみによって制限する（ステップ 1301)ようにしている。このように、リクエストの種 類、転送されるオブジェクトの種類、同時セッション数に科せられた制限を緩めること により、それらの数を制限することができないシステムにおいても、本発明による仲介 装置を適用することが可能となる。
[0119] アプリケーションによっては仲介装置カ モリを段々消費しても、アプリケーション自 身が適当なタイミングで明示的に GCを行うことにより、リクエスト処理中においてゼロ GCを保つことができる場合がある。また、 OSにメモリの追加を要求してもよい。その ようなアプリケーションでは、予め想定されている数より多い数のセッションを同時に サービスしたり、動的にメソッドの種類を増やしたり、あるいは、リクエストで転送される オブジェクトの種類や数を限定しな 、、 t 、う柔軟性を持たせることが可能となる。
[0120] さて、ここで、ハードゼロ GCを実現するために仲介装置に割り当てるべきヒープメモ リの量の算出方法について述べる。そのヒープメモリ量とは、即ち、 GCが発生しない ことを保証するために仲介装置が必要とするメモリ量である。リクエストの種類の集合 を R、あるリクエストにおいて引数あるいは返値及び転送されるデータ及びオブジェク トの種類と数の最大値が占めるメモリの量を P、セッション毎に仲介装置自身が必要と するメモリの量を Tl、仲介装置自身が初期状態で必要とするメモリの量を Τ2、同時 並行セッション数の最大制限値を Sとすると、仲介装置が最低限備えるべきヒープメ モリ量 Mmaxは図 15の式で表される。
[0121] ヒープメモリの最大量算出式により算出した量のヒープメモリを割り当てておき、第 1 の態様の仲介装置のような制限手段により制限を課すことにより、ヒープメモリの使用 量が割当量を超えないことが保証される。逆に、図 15の式を利用すると、割り当てら れたヒープメモリ量力も許される最大セッション数等を求めることも可能である。
[0122] し力し、ヒープメモリの最大量を使用するのは全てのクライアントが全てのリクエスト を同時に発行した極大負荷状態のみである。多くのシステムでは極大負荷状態に至 ることは少ないため、ヒープメモリの最大量を備える必要はない場合もある。ハードゼ 口 GCをより強く保証するため最大ヒープメモリ量に近いメモリを備えることと、ハードゼ 口 GCの破れを許容してヒープメモリ量を削減することはトレードオフ関係にある。シス テムに適合するトレードオフ関係を把握し、仕様上十分なハードゼロ GC保証度に合 わせた適切なヒープメモリ量を与えることもひとつの好ましい実施例である。 [0123] 本発明による仲介装置は、またノヽードウエアを用いて実装することも可能である。ハ 一ドウエアで仲介装置を実装する場合、動的に生成 ·消滅するオブジェクト (ハードウ エアとしてはメモリ上の小領域）の効率的な管理をノヽードウエアで 、かに実現するか が重要なポイントとなる。ハードウェア実装のためのコンポーネントおよびァーキテク チヤは、図 2に示されるシステム構成と同様である。ただし、オブジェクト指向言語を 使用する力否かは問わない。昨今のハードウェア 'ソフトウェア協調設計ツールの進 歩により、一時オブジェクト格納手段や一時オブジェクト管理手段等の本発明の一部 あるいは全部をハードウェア記述言語で記述し、ハードウェアに変換することは困難 ではない。
[0124] 本発明を適用してメモリ管理を行うことにより、メモリの空き領域を大規模に回収する ためのハードウェアを削減することが可能となる。また、メモリ管理のための通信の中 断を抑制することが可能となる。
産業上の利用可能性
[0125] 以上に説明したように、本発明による仲介装置は、 GCを備えるプログラミング言語 で実装されたリクエスト仲介装置、またはメモリ管理を備えるハードウェアで実装され たリクエスト仲介装置におけるリアルタイム性を大幅に向上させるため、ネットワーク上 で通信を行う産業用機器、ロボット、通信デバイス、宇宙機器、自動車等で広く利用 可能である。

Claims

請求の範囲
[1] ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装 されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して 行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
リクエストの種類の制限値を設定するリクエスト種類制限値設定手段と、 前記リクエストの種類の制限値によりリクエストの種類を制限するリクエスト種類制限 手段と、
転送データ数の制限値を設定する転送データ数制限値設定手段と、
前記転送データ数の制限値によりリクエストによって転送されるデータ及びオブジェ タトの種類及び個数を制限する転送データ数制限手段と、
同時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、 前記同時並行使用数の制限値によりリクエストの同時並行使用数を制限する同時 並行使用数制限手段と、
を具備することを特徴とする仲介装置。
[2] 請求項 1に記載の仲介装置において、更に、
前記リクエスト種類制限手段によりリクエストの種類が制限され、
前記転送データ数制限手段によりリクエストによって転送されるデータ及びオブジェ タトの種類及び個数が制限され、または
前記同時並行使用数制限手段によりリクエストの同時並行使用数が制限されて、 リクエストを開始できない場合において、リクエスト処理の開始をタイムウィンドウ時 間の範囲内で延期するリクエスト延期手段を備える
ことを特徴とする仲介装置。
[3] 請求項 1に記載の仲介装置において、更に、
前記一時オブジェクト管理手段を使用するスタブコードを生成するスタブ生成手段 を具備する
ことを特徴とする仲介装置。
[4] 請求項 1に記載の仲介装置において、更に、
一時オブジェクトを必要とするリクエスト仲介処理が開始される前に、一時オブジェ タトが生成されて、前記一時オブジェクト格納手段内に事前配置される、
ことを特徴とする仲介装置。
[5] 請求項 1に記載の仲介装置にお!、て、
前記同時並行使用数制限手段は、クライアントの数もしくは同時に使用されるセッ シヨンの数に基づいて、同時並行使用数制限値を決定し、前記一時オブジェクト格 納手段に事前配置する一時オブジェクトの最大数を決定する、
ことを特徴とする仲介装置。
[6] 請求項 1に記載の仲介装置にお!、て、
前記リクエスト種類制限手段により制限するリクエストの種類の制限値と、転送デー タ数制限手段により制限するリクエストによって転送されるデータ及びオブジェクトの 種類及び個数の制限値と、同時並行使用数制限手段により制限するリクエストの同 時並行使用数の制限値と、前記一時オブジェクト格納手段に事前配置する一時ォブ ジェタトの種類及び個数は、ソースコード、インターフェース定義、サービス定義、プロ グラムメタ情報、コマンド行のオプション指定、設定画面、設定ファイル、コンパイルさ れたプログラムの中の少なくとも一つを解析することによって得ることを特徴とする仲 介装置。
[7] 請求項 1に記載の仲介装置にお!、て、
前記一時オブジェクト管理手段は、ある一時オブジェクトが不変オブジェクトであつ た場合に、その一時オブジェクトを可変オブジェクトに置き換える
ことを特徴とする仲介装置。
[8] 請求項 1に記載の仲介装置において、更に、
ガベージコレクション抑制処理を行うモードと、ガベージコレクション抑制処理を行 なわないモードを切り替える動作モード切替手段を備え、
前記動作モード切替手段が、それぞれの動作モードに応じて一時オブジェクト管理 手段の使用'不使用と、リクエスト種類制限値設定手段に設定する制限値と、転送デ 一タ数制限値設定手段に設定する制限値と、同時並行使用数制限値設定手段に設 定する制限値の各設定値を設定する
ことを特徴とする仲介装置。
[9] ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装 されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して 行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転 送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
の!、ずれかであることを特徴とする仲介装置。
[10] ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装 されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して 行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、 前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転 送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
の!、ずれか 2つであることを特徴とする仲介装置。
[11] ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装 されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して 行う仲介装置におけるメモリの割り当て方法であって、
前記仲介装置が備えるべき最大のヒープメモリ量は、
仲介装置自身が初期状態で必要とするメモリ量に加えて、 1のリクエストにおいて引 数及び返値として転送されるデータの最大メモリ量をリクエスト種類制限値に含まれ るリクエストの種類毎に足し合わせたメモリの量にセッション毎に仲介装置自身が必 要とするメモリの量を加えた量に、同時並行使用数の制限値をかけ算して得られるメ モリ量を割り当てる、
ことを特徴とする仲介装置におけるメモリの割り当て方法。
[12] コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲 介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
リクエストの種類の制限値を設定するリクエスト種類制限値設定手段と、 前記リクエストの種類の制限値によりリクエストの種類を制限するリクエスト種類制限 手段と、
転送データ数の制限値を設定する転送データ数制限値設定手段と、
前記転送データ数の制限値によりリクエストによって転送されるデータ及びオブジェ タトの種類及び個数を制限する転送データ数制限手段と、 同時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、 前記同時並行使用数の制限値によりリクエストの同時並行使用数を制限する同時 並行使用数制限手段と、
を具備することを特徴とする仲介装置。
[13] コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲 介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転 送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
の!、ずれかであることを特徴とする仲介装置。
[14] コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲 介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時 オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管 理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、 リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転 送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
の!、ずれか 2つであることを特徴とする仲介装置。
PCT/JP2006/318485 2005-09-20 2006-09-19 ゼロガベージコレクション通信仲介装置 WO2007034769A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005271297A JP2007086838A (ja) 2005-09-20 2005-09-20 ゼロガベージコレクション通信仲介装置
JP2005-271297 2005-09-20

Publications (1)

Publication Number Publication Date
WO2007034769A1 true WO2007034769A1 (ja) 2007-03-29

Family

ID=37888813

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/318485 WO2007034769A1 (ja) 2005-09-20 2006-09-19 ゼロガベージコレクション通信仲介装置

Country Status (2)

Country Link
JP (1) JP2007086838A (ja)
WO (1) WO2007034769A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103678241A (zh) * 2012-09-25 2014-03-26 日本电气株式会社 存储器管理控制系统以及存储器管理控制方法
US11287995B2 (en) 2020-05-18 2022-03-29 Oracle International Corporation Heap, garbage collection, and empty-sensitive object pools
WO2023098984A1 (en) * 2021-12-01 2023-06-08 Huawei Technologies Co., Ltd. Control unit for controlling a data storage system and method of recovering data from an object storage

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5064134B2 (ja) 2007-08-03 2012-10-31 株式会社日立製作所 メモリ管理方法およびその方法を用いるコンピュータ
JP2010067176A (ja) * 2008-09-12 2010-03-25 Nec Corp 情報処理装置
JP4778035B2 (ja) * 2008-11-07 2011-09-21 インターナショナル・ビジネス・マシーンズ・コーポレーション 外部資源を排他使用しながら実行される命令の実行時間の遅延を防ぐためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP5564540B2 (ja) * 2012-08-08 2014-07-30 株式会社日立製作所 メモリ管理方法、コンピュータ及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6393055A (ja) * 1986-10-07 1988-04-23 Fujitsu Ltd 実時間型ガ−ベジコレクシヨン支援装置
JP2001188704A (ja) * 1999-11-05 2001-07-10 Lucent Technol Inc 時間の制約を持つ分散アプリケーションのためのガーベージコレクション方法
JP2004206644A (ja) * 2002-12-26 2004-07-22 Fujitsu Ltd ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置，そのプログラムおよびプログラム記録媒体
JP2005025727A (ja) * 2003-06-09 2005-01-27 Mitsubishi Electric Corp 情報記憶制御装置及び情報記憶制御方法及び情報記憶制御プログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3690720B2 (ja) * 1999-09-14 2005-08-31 インターナショナル・ビジネス・マシーンズ・コーポレーション クライアントサーバーシステム、オブジェクトのプール方法および記憶媒体
JP4082858B2 (ja) * 2000-10-30 2008-04-30 富士通株式会社 ネットワークアクセス制御方法及びそれを用いたネットワークシステム及びそれを構成する装置
US6947985B2 (en) * 2001-12-05 2005-09-20 Websense, Inc. Filtering techniques for managing access to internet sites or other software applications
JP2004078651A (ja) * 2002-08-20 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> オブジェクトプーリング装置および方法とプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6393055A (ja) * 1986-10-07 1988-04-23 Fujitsu Ltd 実時間型ガ−ベジコレクシヨン支援装置
JP2001188704A (ja) * 1999-11-05 2001-07-10 Lucent Technol Inc 時間の制約を持つ分散アプリケーションのためのガーベージコレクション方法
JP2004206644A (ja) * 2002-12-26 2004-07-22 Fujitsu Ltd ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置，そのプログラムおよびプログラム記録媒体
JP2005025727A (ja) * 2003-06-09 2005-01-27 Mitsubishi Electric Corp 情報記憶制御装置及び情報記憶制御方法及び情報記憶制御プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIRANO S.: "Bunsan Java Jikkokei HORB no Kihon Seino no Hyoka", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU (97-OS-76), SHADAN HOJIN INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 97, no. 77, 21 August 1997 (1997-08-21), pages 67 - 72, XP003010840 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103678241A (zh) * 2012-09-25 2014-03-26 日本电气株式会社 存储器管理控制系统以及存储器管理控制方法
CN103678241B (zh) * 2012-09-25 2018-07-31 日本电气株式会社 存储器管理控制系统以及存储器管理控制方法
US11287995B2 (en) 2020-05-18 2022-03-29 Oracle International Corporation Heap, garbage collection, and empty-sensitive object pools
WO2023098984A1 (en) * 2021-12-01 2023-06-08 Huawei Technologies Co., Ltd. Control unit for controlling a data storage system and method of recovering data from an object storage

Also Published As

Publication number Publication date
JP2007086838A (ja) 2007-04-05

Similar Documents

Publication Publication Date Title
US8713186B2 (en) Server-side connection resource pooling
Schmidt et al. Object-Oriented Components for High-speed Network Programming.
JP3730563B2 (ja) セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体
WO2007034769A1 (ja) ゼロガベージコレクション通信仲介装置
US20060242641A1 (en) Method and system for a resource negotiation between virtual machines
US20050198079A1 (en) Process and system for real-time relocation of objects during garbage collection
US20060010234A1 (en) Dynamic provisioning of service components in a distributed system
US8296774B2 (en) Service-based endpoint discovery for client-side load balancing
US8701095B2 (en) Add/remove memory pressure per object
US20040148605A1 (en) Distributed processing system and method using virtual machine
WO2018045541A1 (zh) 一种容器分配的优化方法及处理设备
US7774405B2 (en) Coordination of set enumeration information between independent agents
US20060248130A1 (en) Process and system for real-time relocation of objects during garbage collection
White et al. The GC interface in the EVM
Bromberg et al. Automatic generation of network protocol gateways
US8442939B2 (en) File sharing method, computer system, and job scheduler
Denis et al. Achieving portable and efficient parallel CORBA objects
US20040006637A1 (en) Methods and systems for transmitting application software
Campos et al. The chance for Ada to support distribution and real-time in embedded systems
CN113641641A (zh) 文件存储服务的切换方法、切换系统、设备及存储介质
Govindaraju et al. XCAT-C++: Design and performance of a distributed CCA framework
US11689621B2 (en) Computing device and storage card
Krishna et al. Enhancing real-time CORBA predictability and performance
WO2024123341A1 (en) Allocating dedicated shared cpu
Kurmann et al. Zero-Copy for CORBA-Efficient Communication for Distributed Object Middleware.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06798096

Country of ref document: EP

Kind code of ref document: A1