CA2701503A1 - Remote caching of an identifier - Google Patents
Remote caching of an identifier Download PDFInfo
- Publication number
- CA2701503A1 CA2701503A1 CA2701503A CA2701503A CA2701503A1 CA 2701503 A1 CA2701503 A1 CA 2701503A1 CA 2701503 A CA2701503 A CA 2701503A CA 2701503 A CA2701503 A CA 2701503A CA 2701503 A1 CA2701503 A1 CA 2701503A1
- Authority
- CA
- Canada
- Prior art keywords
- identifier
- cache
- requested
- program code
- computer
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 124
- 230000004044 response Effects 0.000 claims abstract description 42
- 230000008569 process Effects 0.000 claims abstract description 41
- 238000004891 communication Methods 0.000 claims description 44
- 230000015654 memory Effects 0.000 claims description 25
- 239000004744 fabric Substances 0.000 claims description 22
- 238000004590 computer program Methods 0.000 claims description 20
- 238000013507 mapping Methods 0.000 claims description 5
- 238000012545 processing Methods 0.000 description 34
- 238000003860 storage Methods 0.000 description 33
- 238000010586 diagram Methods 0.000 description 18
- 230000002085 persistent effect Effects 0.000 description 14
- 230000006870 function Effects 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 239000000463 material Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000032683 aging Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000368 destabilizing effect Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
An illustrative embodiment of a computer-implemented process for remote caching of an identifier receives a request for an identifier associated with a class to form a requested identifier, maps the local identifier for the class in the requested identifier to a unique class identifier to form a requested identifier, determines whether the requested identifier is in a cache and responsive to a determination that the requested identifier is not in the cache, sends the request to a virtual machine. The computer-implemented process receives a response identifier including a unique class identifier from the virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester.
Description
REMOTE CACHING OF AN IDENTIFIER
BACKGROUND
1. Technical Field:
[0001] This disclosure relates generally to remote processing in a data processing system and more specifically to remote caching of an identifier for JavaTM Native Interface offloads using a Java virtual machine in the data processing system.
BACKGROUND
1. Technical Field:
[0001] This disclosure relates generally to remote processing in a data processing system and more specifically to remote caching of an identifier for JavaTM Native Interface offloads using a Java virtual machine in the data processing system.
2. Description of the Related Art:
[0002] Java virtual machine (JVM) implementations support the Java Native Interface (JNI) as a mechanism, which allows Java code to call methods written in C and C++ (native code) and methods written in C and C++ to call Java code. Traditionally both the code written in Java and the native code is executed in the same process and by the same thread as execution transitions between the two environments.
[0002] Java virtual machine (JVM) implementations support the Java Native Interface (JNI) as a mechanism, which allows Java code to call methods written in C and C++ (native code) and methods written in C and C++ to call Java code. Traditionally both the code written in Java and the native code is executed in the same process and by the same thread as execution transitions between the two environments.
[0003] It is possible, however, to construct a Java virtual machine such that the native code is run in one or more remote execution containers forming a split Java virtual machine. The remote execution containers may be hosted in separate processes on the same machine or different machines from where the Java code is executed. In remote execution the native code is unaware that it is executing separately from the Java virtual machine. This separation prevents misbehaved native code from destabilizing the Java virtual machine and enables running the native code in a different environment, for example, security context, or bit width than the main Java virtual machine.
[0004] In a split Java virtual machine the cost of the calls between Java and native.code have much greater overhead and latency resulting in the need to reduce round-trips where possible. In such a system where native code, also referred to as natives, execute remotely from the Java virtual machine natives need to interact with classes by getting and setting field values and invoking methods. The natives must first obtain a field or method identifier that is used to get and set the field or invoke the method. In systems where natives run in the same process as the Java virtual machine the overhead in getting the field and method identifiers is low. However, this is not the case when natives are run remotely. The standardized Java Native Interface form of interface used by all current natives only allows the natives to obtain a single method or field identifier per call. Therefore obtaining each identifier will require an expensive remote call.
[0005] Consider the following code snippet in which a remote execution sequence occurs.
Al: jmethod method = (*env)->GetStaticMethodlD(env, cls, "setlnfo", "(I)V");
A2: (*env)->CallStaticVoidMethod(env, cls, method,val);
A3: jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
A4: jint avalue =(*env)->GetIntFie1d(env, ailValues, a);
B 1: jmethod method =(*env)->GetStaticMethodID(env, cls, "setInfo", "(I)V");
B2: (*env)->Ca1lStaticVoidMethod(env, cls, method,val);
B3: jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
B4: jint avalue =(*env)->GetIntFie1d(env, a1lValues, a);
Al: jmethod method = (*env)->GetStaticMethodlD(env, cls, "setlnfo", "(I)V");
A2: (*env)->CallStaticVoidMethod(env, cls, method,val);
A3: jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
A4: jint avalue =(*env)->GetIntFie1d(env, ailValues, a);
B 1: jmethod method =(*env)->GetStaticMethodID(env, cls, "setInfo", "(I)V");
B2: (*env)->Ca1lStaticVoidMethod(env, cls, method,val);
B3: jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
B4: jint avalue =(*env)->GetIntFie1d(env, a1lValues, a);
[0006] There is an expensive round trip to get the field or method identifier each time the native wishes to access a field or call a method. Of course when the same field or method is used within the same native there is no need to perform a look up twice. The example is intended to illustrate a case where there are multiple calls to the native. The native performs the lookup or calls to different natives, which need to use the same field or method.
Therefore the field or method identifier is needed but is not accessible to the copy of the field or method identifier retrieved earlier. It is also important to note that the identifier used by a native, to identify a class to which field and method identifiers are associated, may be unique to a specific invocation of the native. For example, the class identifier used in calls to GetFieldID
and GetStaticMethodMethodlD shown in the code snippet may be different in each invocation of the native, even when the class is identical. The difference can occur because the class identifiers may be local references, which are invocation specific as opposed to being unique across invocations.
BRIEF SUMMARY
Therefore the field or method identifier is needed but is not accessible to the copy of the field or method identifier retrieved earlier. It is also important to note that the identifier used by a native, to identify a class to which field and method identifiers are associated, may be unique to a specific invocation of the native. For example, the class identifier used in calls to GetFieldID
and GetStaticMethodMethodlD shown in the code snippet may be different in each invocation of the native, even when the class is identical. The difference can occur because the class identifiers may be local references, which are invocation specific as opposed to being unique across invocations.
BRIEF SUMMARY
[0007] According to one embodiment, a computer-implemented process for remote caching of an identifier receives a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier, maps the local identifier for the particular class included in the request to a unique class identifier and determines, using the previously mapped unique class identifier, whether the requested identifier is in a cache.
Responsive to a determination that the requested identifier is not in the cache, send the request to a virtual machine. The computer-implemented process receives a response identifier including an identifier from the virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester.
Responsive to a determination that the requested identifier is not in the cache, send the request to a virtual machine. The computer-implemented process receives a response identifier including an identifier from the virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester.
[0008] According to another embodiment, a computer program product for remote caching of an identifier comprises a computer recordable-type media containing computer executable program code stored thereon. The computer executable program code comprises computer executable program code for receiving a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier, computer executable program code for mapping the local identifier for the particular class included in the request to a unique class identifier, computer executable program code for determining using the previously mapped unique class identifier whether the requested identifier is in a cache, computer executable program code responsive to a determination that the requested identifier is not in the cache, for sending the request to a virtual machine, computer executable program code for receiving a response identifier including an identifier from the virtual machine, computer executable program code for populating the cache with the response identifier using the previously mapped unique class identifier and computer executable program code for returning the requested identifier to a requester.
[0009] According to another embodiment, an apparatus for remote caching of an identifier comprises a communications fabric, a memory connected to the communications fabric, wherein the memory contains computer executable program code, a communications unit connected to the communications fabric, an input/output unit connected to the communications fabric, a display connected to the communications fabric and a processor unit connected to the communications fabric. The processor unit executes the computer executable program code to direct the apparatus to receive a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier, map the local identifier for the particular class included in the request to a unique class identifier, determine using the previously mapped unique class identifier whether the requested identifier is in a cache, responsive to a determination that the requested identifier is not in the cache, send the request to a virtual machine, receive a response identifier including an identifier from the virtual machine, populate the cache with the response identifier using the previously mapped unique class identifier and return the requested identifier to a requester.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0010] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
[0011] Figure 1 is a block diagram of an exemplary data processing system operable for various embodiments of the disclosure;
[0012] Figure 2; is a block diagram of a system with a remote execution container in accordance with various embodiments of the disclosure;
[0013] Figure 3 is a block diagram of a cache data structure of the remote execution container of Figure 2 in accordance with one embodiment of the disclosure;
[0014] Figure 4 is a block diagram of a system of multiple remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure;
[0015] Figure 5 is a flowchart of a process using the remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure.
DETAILED DESCRIPTION
DETAILED DESCRIPTION
[0016] Although an illustrative implementation of one or more embodiments is provided below, the disclosed systems and/or methods may be implemented using any number of techniques.
This disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
This disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
[0017] As will be appreciated by one skilled in the art, the present disclosure may be embodied as a system, method or computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit,"
"module," or "system." Furthermore, the present invention may take the form of a computer program product tangibly embodied in any medium of expression with computer usable program code embodied in the medium.
"module," or "system." Furthermore, the present invention may take the form of a computer program product tangibly embodied in any medium of expression with computer usable program code embodied in the medium.
[0018] Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as JavaTM, Smalltalk, C++, or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc., in the United States, other countries or both. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
[0019] The present disclosure is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions.
[0020] These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
[0021) The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
[0022] Turning now to Figure 1 a block diagram of an exemplary data processing system operable for various embodiments of the disclosure is presented. In this illustrative example, data processing system 100 includes communications fabric 102, which provides communications between processor unit 104, memory 106, persistent storage 108, communications unit 110, input/output (UO) unit 112, and display 114.
[0023] Processor unit 104 serves to execute instructions for software that may be loaded into memory 106. Processor unit 104 may be a set of one or more processors or may be a multi-processor core, depending on the particular implementation. Further, processor unit 104 may be implemented using one or more heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, processor unit 104 may be a symmetric multi-processor system containing multiple processors of the same type.
[0024] Memory 106 and persistent storage 108 are examples of storage devices 116. A storage device is any piece of hardware that is capable of storing information, such as, for example without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Memory 106, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 108 may take various forrns depending on the particular implementation. For example, persistent storage 108 may contain one or more components or devices. For example, persistent storage 108 may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above.
The media used by persistent storage 108 also may be removable. For example, a removable hard drive may be used for persistent storage 108.
The media used by persistent storage 108 also may be removable. For example, a removable hard drive may be used for persistent storage 108.
[0025] Communications unit 110, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 110 is a network interface card. Communications unit 110 may provide communications through the use of either or both physical and wireless communications links.
[0026] Input/output unit 112 allows for input and output of data with other devices that may be connected to data processing system 100. For example, input/output unit 112 may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device.
Further, input/output unit 112 may send output to a printer. Display 114 provides a mechanism to display information to a user.
Further, input/output unit 112 may send output to a printer. Display 114 provides a mechanism to display information to a user.
[0027] Instructions for the operating system, applications andlor programs may be located in storage devices 116, which are in communication with processor unit 104 through communications fabric 102. In these illustrative examples the instructions are in a functional form on persistent storage 108. These instructions may be loaded into memory 106 for execution by processor unit 104. The processes of the different embodiments may be performed by processor unit 104 using computer-implemented instructions, which may be located in a memory, such as memory 106.
100281 These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and executed by a processor in processor unit 104. The program code in the different embodiments may be embodied on different physical or tangible computer readable media, such as memory 106 or persistent storage 108.
[0029] Program code 118 is located in a functional forrn on computer readable media 120 that is selectively removable and may be loaded onto or transferred to data processing system 100 for execution by processor unit 104. Program code 118 and computer readable media 120 form computer program product 122 in these examples. In one example, computer readable media 120 may be in a tangible form, such as, for example, an optical or magnetic disc that is inserted or placed into a drive or other device that is part of persistent storage 108 for transfer onto a storage device, such as a hard drive that is part of persistent storage 108.
In a tangible form, computer readable media 120 also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory that is connected to data processing system 100. The tangible form of computer readable media 120 is also referred to as computer recordable storage media.
In some instances, computer readable media 120 may not be removable.
[0030] Alternatively, program code 118 may be transferred to data processing system 100 from computer readable media 120 through a communications link to communications unit 110 and/or through a connection to input/output unit 112. The communications link and/or the connection may be physical or wireless in the illustrative examples. The computer readable media also may take the form of non-tangible media, such as communications links or wireless transmissions containing the program code.
[0031] In some illustrative embodiments, program code 118 may be downloaded over a network to persistent storage 108 from another device or data processing system for use within data processing system 100. For instance, program code stored in a computer readable storage medium in a server data processing system may be downloaded over a network from the server to data processing system 100. The data processing system providing program code 118 may be a server computer, a client computer, or some other device capable of storing and transmitting program code 118.
[0032] The different components illustrated for data processing system 100 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system 100. Other components shown in Figure 1 can be varied from the illustrative examples shown. The different embodiments may be implemented using any hardware device or system capable of executing program code. As one example, the data processing system may include organic components integrated with inorganic components and/or may be comprised entirely of organic components excluding a human being. For example, a storage device may be comprised of an organic semiconductor.
[0033] As another example, a storage device in data processing system 100 may be any hardware apparatus that may store data. Memory 106, persistent storage 108 and computer readable media 120 are examples of storage devices in a tangible form.
[0034] In another example, a bus system may be used to implement communications fabric 102 and may be comprised of one or more buses, such as a system bus or an input/output bus. Of course, the bus system may be implemented using any suitable type of architecture that provides for a transfer of data between different components or devices attached to the bus system.
Additionally, a communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. Multiple systems, such as system data processing system 100, may then be connected to form a network of data processing systems of data processing system 100. Further, a memory may be, for example, memory 106 or a cache such as found in an interface and memory controller hub that may be present in communications fabric 102.
[0035] According to an illustrative embodiment, a computer-implemented process for remote caching of an identifier is executed in a distributed Java virtual machine in which the Java Native Interface implementation has been enhanced to send an additional unique class identifier to a remote execution container for each invocation specific class identifier exchanged with the Java virtual machine. The Java Native Interface implementation is further enhanced to maintain a table, of invocation specific/unique identifiers, associated with a remote execution container and receives a request for a field identifier or method identifier associated with a particular class, in which an invocation specific identifier, that forms an identifier request, specifies the class. The invocation specific identifier for the class is mapped to a unique class identifier using the table maintained by the remote execution container. The remote execution container determines whether the requested identifier is in a cache based on the unique class identifier and other information in the identifier request. Responsive to a determination that the identifier is not in the cache, the remote execution container sends the request to the Java virtual machine. The computer-implemented process receives a response including the identifier, and populates the cache of the remote execution container with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester.
[0036] Using data processing system 100 of Figure 1 as an example, an illustrative embodiment provides a computer-implemented process for remote caching of an identifier stored in memory 106, executed by processor unit 104. Processor unit 104 receives a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier from communications unit 110, input/output unit 112, storage devices 116 or display 114, and determines, using the previously mapped unique class identifier, whether the requested identifier is in a cache contained in storage devices 116.
Responsive to a determination that the requested identifier is not in the cache, processor unit 104 sends the request to an enhanced virtual machine using communications unit 110.
Processor unit 104 receives a response identifier including a field identifier or a method identifier from the virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester using communications unit 110 or placement in storage devices 116 for retrieval.
[0037] In an alternative embodiment, program code 118 containing the computer-implemented process may be stored within computer readable media 120 as computer program product 122.
In another illustrative embodiment, the process for remote identifier caching may be implemented in an apparatus comprising a communications fabric, a memory connected to the communications fabric, wherein the memory contains computer executable program code, a communications unit connected to the communications fabric, an input/output unit connected to the communications fabric, a display connected to the communications fabric, and a processor unit connected to the communications fabric. The processor unit of the apparatus executes the computer executable program code to direct the apparatus to perform the process.
[0038] With reference to Figure 2, a block diagram of a system with a remote execution container in accordance with various embodiments of the disclosure is presented. System 200 is an example of a system with a remote execution container and associated cache for containing and managing method and field identifiers from a Java virtual machine. System 200 consists of a number of components comprising Java virtual machine 202, remote execution container 204 and cache 206.
[0039] Cache 206 further contains data structures representing class information received from Java virtual machine 202. The class information is contained in collections identified as collection 208, collection 210 and collection 212. A unique class identifier identifies each collection. A further data structure, table 214, is created to manage a relationship between a local reference identifier and unique class identifier. In the example, table 214 is a correspondence table in which a local reference identifier and a corresponding unique class identifier may be paired. The pairing provides a look-up reference between the local reference identifier and corresponding unique class identifier used to locate a specific collection.
[0040] Java Native Interface calls are made between Java virtual machine 202 and remote execution container 204. Request 216 for a field identifier or a method identifier is sent to Java virtual machine 202. Response 218 containing the requested information including a unique class identifier is sent to remote execution container 204. A class with a given name may be loaded multiple times using different classloaders and may even be loaded and unloaded by the same classloader. Each time a class is loaded it may have different fields and methods. Even in cases where the class has the same fields and methods the prior field and method identifiers will be invalid after another class load. While non-unique identifiers are used in the Java Native Interface calls, Java virtual machine 202 maintains a unique class identifier or can be made to keep a unique identifier, for each class. Remote execution container 204 includes an enhanced Java Native Interface implementation that maintains a data structure of pairings of invocation specific/unique identifiers with the help of enhanced Java virtual machine 202. The Java Native interface implementation provided by Java virtual machine 202 and remote execution container 204 is thus enhanced to create and manage a pairing of class invocation/unique identifiers and to further support caching of field and method identifiers for use by remote execution container 204.
[0041] Remote execution container 204 using cache 206 caches information contained in response 218 in operation 220. Caching method identifiers and field identifiers reduces the number of expensive remote calls to Java virtual machine 202 from remote execution container 204. The method identifiers and field identifiers do not change over the lifetime of a loaded class. The method identifiers and field identifiers are valid across all threads within Java virtual machine 202 as opposed to being only thread-local. Integration with class loading technology within Java virtual machine 202 enables cached field identifiers and method identifiers to only remain in the cache while useful.
[0042] Applying this technique enables subsequent call 222 for the field identifier or method identifier to be resolved using cache 206. Response 224 resolves subsequent call 222 through lookup of the unique identifier from table 214 and then locates the requested information in one of collection 208, collection 210 or collection 212. Subsequent remote calls to Java virtual machine 202 to retrieve a field identifier or method identifier are eliminated thereby reducing the number of expensive remote calls to 1 from N when the field identifier or method identifier is used N times, thus eliminating N-1 round trips. Rather than making one call for the class lookup and one call for the use of the field identifier or the method identifier to Java virtual machine 202, after the initial call only remote execution container 204 call for the use of the field or method is needed.
[0043] When a class is no longer needed an unsolicited class unload notice 226 may be sent from Java virtual machine 202 to remote execution container 204 to free storage in cache 206. In another operation, when local references are no longer required, remote execution container 204 may perform a delete local reference request 228 to remove references that are no longer useful from table 214.
[0044] With reference to Figure 3, a block diagram of a cache data structure of the remote execution container of Figure 2 is presented in accordance with one embodiment of the disclosure. Cache data structure 300 is an example of cache 206 of Figure 2.
[0045] Table 302 is an example of table 214 of Figure 2 containing local reference ID1 310, unique class ID 1 312, local reference IDn 314 and unique class IDn 316. A
unique class identifier, such as unique class ID 1 312, is used as a key or pointer 318 into a subset of the cache, such as collection 304, that holds field and method identifiers for the particular class.
Collection 304 removes the need for repeatedly accessing information available in Java virtual machine 202 of Figure 2 through the class identifier but which is otherwise not previously available to the native of remote execution container 204 of Figure 2 when executing remotely.
Unique class IDn 316 is used as a key or pointer 320 into a subset of the cache, such as collection 306 in a similar manner. The unique class identifier is used to add and obtain field identifiers and method identifiers from cache 300.
[0046] The initial request using the application programming interface for a field or method identifier will make the required remote call from remote execution container 204 of Figure 2 to get the field identifier or method identifier from Java virtual machine 202 of Figure 2. The remote execution container will populate one of collection 304, or collection 306 or collection 308 of cache 300, or create a new container as required and return the identifier as requested to the caller. Subsequent requests for the field identifier or method identifier, whether from the same thread or a different thread because field identifiers and method identifiers are valid across threads, will locate a copy of a requested identifier within cache 300 and return the field or method identifier without requiring an expensive remote call to Java virtual machine 202 of Figure 2. Through this technique the expensive remote call for all but the first request to lookup a method identifier or field identifier is resolved at the remote execution container.
[0047] A jclass (the identifier for a class) returned to the Java Native Interface method is a local reference that is only valid for the lifespan of the invocation of that method. Different invocations of a Java Native Interface method or invocations of different Java Native Interface methods to lookup field or method identifiers for a particular class pass a different jclass to the method than the jclass from previous invocations. Therefore the value of the jclass passed in cannot be used as the key or pointer directly in the cache.
[0048] In a typical virtual machine the current value of the jclass can be converted to a unique value representing the actual class. However in a split virtual machine, doing the same thing would require an expensive remote call back to the Java virtual machine.
[0049] In an embodiment of the disclosed enhanced Java process a determination is made as to whether a given jobject is a jclass or not. When passing a jobject, which is a jclass to a remote execution container, a unique value, such as unique class ID1 312 is sent along with local reference ID 1 310. Unique class ID 1 312 can either be derived from a constant known value that already exists given an particular implementation of the Java virtual machine or be provided by extending fields within java.lang.Class to hold a unique value for every class.
[0050] In the remote execution container, such as remote execution container 204 of Figure 2, the additional unique class value is placed into a data structure such as table 214 enabling the unique class value to be obtained given the corresponding local reference. An entry from the data structure will be removed either when a corresponding local reference is deleted through a call, such as, DeleteLocalRef or when the native to which the local reference was passed terminates. In this way the additional inforrnation and the associated storage will only be retained while a possible use remains.
[0051] When a request to lookup a field or method identifier is received, local reference such as local reference ID1 310, is used to lookup the corresponding unique value such as unique class ID 1 312 for the jclass. The unique value is used to perform a lookup for an entry and an add operation of an entry using cache 300 when necessary.
[0052] With reference to Figure 4, a block diagram of a system of multiple remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure is presented. System 400 is an example of system 200 of Figure 2 with two remote execution containers in use.
[0053] Cache management ensures the cache does not grow without bound and the entries contained within are always valid. Cache management removes entries for classes, which are no longer valid. Cache management is performed in a way that does not require an expensive remote call for each field identifier or method identifier request. Field identifiers and method identifiers remain valid at most until the associated class is unloaded in the Java virtual machine.
[0054] In an example, Java virtual machine 402 creates an unsolicited class unload event sent from garbage collector 404 as event notice 410 and event notice 412 to remote execution container 1 406 and remote execution container N 408 in which methods and fields have been cached.
[0055] Since fields and methods may be looked up and used many times over the lifetime of a class the net number of remote calls will be reduced. This base approach can be further optimized using one, or any combination of the following techniques. For example, maintaining a unique identifier for a classloader associated with each class for which field identifiers and method identifiers in the cache. Garbage collector 404 sends a single classloader unload event, such as event 410, when a classloader is unloaded, to remove the entries for all classes loaded by that classloader with only a single remote call. Unloading a classloader typically triggers unloading many associated classes.
[0056] In another example, when performing a look up of method identifiers and field identifiers for the first time a remote call, that obtains the field identifier or the method identifier, also registers the issuing remote native execution container, such as remote execution container N
408, is interested in unload events for the specific class and or classloader.
Garbage collector 404 only sends unload events to remote execution container 404 that cached methods or fields for the class.
[0057] In another example, batching unload calls from garbage collector 404 enables sending the unload message when a number of classes unloaded reaches a predetermined threshold value.
The unload messages may be sent for all such classes in a single unsolicited remote call.
[0058] In another example, an initial remote call for a new field or method is expanded to enable a returned result to provide additional information on which classes can be removed from the cache. The addition of the information reduces or eliminates the unsolicited class unload events.
Class unload information may also be compressed before transmission to reduce overhead.
Typical cache aging and least recently used techniques may also be used to remove entries from the cache.
[0059] The example of system 400 provides for each remote execution container to have an associated cache. In a variation, the cache of a set of remote execution containers may be shared across multiple remote execution containers on the same machine.
[0060] With reference to Figure 5, a flowchart of a process using the remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure. Process 500 is an example of using system 200 of Figure 2 for remote identifier caching to reduce the frequency of remote calls when using remote execution containers with a Java virtual machine.
[0061] Process 500 depicts a flow of operations after the initial exchange of class information has occurred. Populating a cache includes adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier. In one illustrative embodiment, the correspondence entry may be contained within a table. Other implementation examples to manage the pairing of unique class identifier and a local reference identifier suitable for performing a lookup may be used.
[0062] There cannot be a case were there is not a local identifier to class unique correspondence mapping. Because when the Java virtual machine sends the native (remote execution container) a local identifier for the class the Java virtual machine will also send the class unique identifier. In this way any time the native makes a request with the local identifier, there will already be a corresponding local identifier to class unique correspondence mapping in the table managed by the remote execution container.
[0063] Process 500 begins (step 502) and receives a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier (step 504). Process 500 maps the local class identifier in the requested identifier to the unique identifier for the class (step 506). Process 500 determines, using the previously mapped unique class identifier, whether the requested identifier is in a cache (step 508).
The cache may be associated with one or more remote execution containers. When a determination is made that the requested identifier is in the cache, a "yes" result is obtained. When a determination is made that the requested identifier is not in the cache, a "no" result is obtained.
[0064] When a "no" result is obtained in step 508, process 500 sends the request to an enhanced Java virtual machine (step 510). The enhanced Java virtual machine includes an enhanced implementation of Java Native Interface. Process 500 receives a response identifier including a field identifier or a method identifier from the Java virtual machine (step 512).
[0065] Process 500 populates a cache with the response identifier using the previously mapped unique class identifier (step 514). Populating the cache creates data structures for a collection in which each collection includes a unique class identifier and an associated set of field identifiers and method identifiers. The set of field identifiers and method identifiers includes one or more entries of field identifiers and method identifiers or field identifiers or method identifiers as required.
[0066] Process 500 returns the requested identifier to a requester (step 516), terminating thereafter (step 518). The requested identifier may be returned from the cache after the cache is populated or before the population operation is completed.
When a "yes" result is obtained in step 508, process 500 obtains the requested identifier from the cache (step 520). Process 500 returns the requested identifier to a requester as before (step 516), terminating thereafter (step 518). Returning the requested identifier from the cache to a requester may further comprise determining whether the response identifier is needed in the cache and responsive to a determination that the response identifier is not needed in the cache, removing selected entries from the cache [0067] Thus is described in one embodiment, a computer-implemented process for remote caching of an identifier is executed in a distributed Java virtual machine in which a Java Native Interface implementation has been enhanced to send an additional unique class identifier to a remote execution container for each invocation specific class identifier exchanged with the Java virtual machine. The remote execution container further keeps a table of pairings of invocation specific/unique identifiers, receives a request for a field or method identifier associated with a particular class, given a local identifier for the particular class specified, to form a requested identifier, maps the local identifier for the particular class included in the request to a unique class identifier using the table maintained by the remote execution container, determines using the previously mapped unique class identifier, whether the requested identifier is in a cache.
Responsive to a determination that the identifier is not in the cache the request is sent to the Java virtual machine. The computer-implemented process receives a response identifier including a field identifier or a method identifier from the Java virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester. The enhancement to the Java virtual machine and remote execution container provides a capability to send a local/unique identifier for each jobject which is a class, either through invocation of Java Native Interface methods or when a Java Native Interface callback is made.
[0068] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the block might occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
[0069] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.
The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed.
Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
[00100]The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, and other software media that may be recognized by one skilled in the art.
[00101]It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
[00102]A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[00103]Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening UO controllers.
[00104]Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.
[00105]The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
100281 These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and executed by a processor in processor unit 104. The program code in the different embodiments may be embodied on different physical or tangible computer readable media, such as memory 106 or persistent storage 108.
[0029] Program code 118 is located in a functional forrn on computer readable media 120 that is selectively removable and may be loaded onto or transferred to data processing system 100 for execution by processor unit 104. Program code 118 and computer readable media 120 form computer program product 122 in these examples. In one example, computer readable media 120 may be in a tangible form, such as, for example, an optical or magnetic disc that is inserted or placed into a drive or other device that is part of persistent storage 108 for transfer onto a storage device, such as a hard drive that is part of persistent storage 108.
In a tangible form, computer readable media 120 also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory that is connected to data processing system 100. The tangible form of computer readable media 120 is also referred to as computer recordable storage media.
In some instances, computer readable media 120 may not be removable.
[0030] Alternatively, program code 118 may be transferred to data processing system 100 from computer readable media 120 through a communications link to communications unit 110 and/or through a connection to input/output unit 112. The communications link and/or the connection may be physical or wireless in the illustrative examples. The computer readable media also may take the form of non-tangible media, such as communications links or wireless transmissions containing the program code.
[0031] In some illustrative embodiments, program code 118 may be downloaded over a network to persistent storage 108 from another device or data processing system for use within data processing system 100. For instance, program code stored in a computer readable storage medium in a server data processing system may be downloaded over a network from the server to data processing system 100. The data processing system providing program code 118 may be a server computer, a client computer, or some other device capable of storing and transmitting program code 118.
[0032] The different components illustrated for data processing system 100 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system 100. Other components shown in Figure 1 can be varied from the illustrative examples shown. The different embodiments may be implemented using any hardware device or system capable of executing program code. As one example, the data processing system may include organic components integrated with inorganic components and/or may be comprised entirely of organic components excluding a human being. For example, a storage device may be comprised of an organic semiconductor.
[0033] As another example, a storage device in data processing system 100 may be any hardware apparatus that may store data. Memory 106, persistent storage 108 and computer readable media 120 are examples of storage devices in a tangible form.
[0034] In another example, a bus system may be used to implement communications fabric 102 and may be comprised of one or more buses, such as a system bus or an input/output bus. Of course, the bus system may be implemented using any suitable type of architecture that provides for a transfer of data between different components or devices attached to the bus system.
Additionally, a communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. Multiple systems, such as system data processing system 100, may then be connected to form a network of data processing systems of data processing system 100. Further, a memory may be, for example, memory 106 or a cache such as found in an interface and memory controller hub that may be present in communications fabric 102.
[0035] According to an illustrative embodiment, a computer-implemented process for remote caching of an identifier is executed in a distributed Java virtual machine in which the Java Native Interface implementation has been enhanced to send an additional unique class identifier to a remote execution container for each invocation specific class identifier exchanged with the Java virtual machine. The Java Native Interface implementation is further enhanced to maintain a table, of invocation specific/unique identifiers, associated with a remote execution container and receives a request for a field identifier or method identifier associated with a particular class, in which an invocation specific identifier, that forms an identifier request, specifies the class. The invocation specific identifier for the class is mapped to a unique class identifier using the table maintained by the remote execution container. The remote execution container determines whether the requested identifier is in a cache based on the unique class identifier and other information in the identifier request. Responsive to a determination that the identifier is not in the cache, the remote execution container sends the request to the Java virtual machine. The computer-implemented process receives a response including the identifier, and populates the cache of the remote execution container with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester.
[0036] Using data processing system 100 of Figure 1 as an example, an illustrative embodiment provides a computer-implemented process for remote caching of an identifier stored in memory 106, executed by processor unit 104. Processor unit 104 receives a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier from communications unit 110, input/output unit 112, storage devices 116 or display 114, and determines, using the previously mapped unique class identifier, whether the requested identifier is in a cache contained in storage devices 116.
Responsive to a determination that the requested identifier is not in the cache, processor unit 104 sends the request to an enhanced virtual machine using communications unit 110.
Processor unit 104 receives a response identifier including a field identifier or a method identifier from the virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester using communications unit 110 or placement in storage devices 116 for retrieval.
[0037] In an alternative embodiment, program code 118 containing the computer-implemented process may be stored within computer readable media 120 as computer program product 122.
In another illustrative embodiment, the process for remote identifier caching may be implemented in an apparatus comprising a communications fabric, a memory connected to the communications fabric, wherein the memory contains computer executable program code, a communications unit connected to the communications fabric, an input/output unit connected to the communications fabric, a display connected to the communications fabric, and a processor unit connected to the communications fabric. The processor unit of the apparatus executes the computer executable program code to direct the apparatus to perform the process.
[0038] With reference to Figure 2, a block diagram of a system with a remote execution container in accordance with various embodiments of the disclosure is presented. System 200 is an example of a system with a remote execution container and associated cache for containing and managing method and field identifiers from a Java virtual machine. System 200 consists of a number of components comprising Java virtual machine 202, remote execution container 204 and cache 206.
[0039] Cache 206 further contains data structures representing class information received from Java virtual machine 202. The class information is contained in collections identified as collection 208, collection 210 and collection 212. A unique class identifier identifies each collection. A further data structure, table 214, is created to manage a relationship between a local reference identifier and unique class identifier. In the example, table 214 is a correspondence table in which a local reference identifier and a corresponding unique class identifier may be paired. The pairing provides a look-up reference between the local reference identifier and corresponding unique class identifier used to locate a specific collection.
[0040] Java Native Interface calls are made between Java virtual machine 202 and remote execution container 204. Request 216 for a field identifier or a method identifier is sent to Java virtual machine 202. Response 218 containing the requested information including a unique class identifier is sent to remote execution container 204. A class with a given name may be loaded multiple times using different classloaders and may even be loaded and unloaded by the same classloader. Each time a class is loaded it may have different fields and methods. Even in cases where the class has the same fields and methods the prior field and method identifiers will be invalid after another class load. While non-unique identifiers are used in the Java Native Interface calls, Java virtual machine 202 maintains a unique class identifier or can be made to keep a unique identifier, for each class. Remote execution container 204 includes an enhanced Java Native Interface implementation that maintains a data structure of pairings of invocation specific/unique identifiers with the help of enhanced Java virtual machine 202. The Java Native interface implementation provided by Java virtual machine 202 and remote execution container 204 is thus enhanced to create and manage a pairing of class invocation/unique identifiers and to further support caching of field and method identifiers for use by remote execution container 204.
[0041] Remote execution container 204 using cache 206 caches information contained in response 218 in operation 220. Caching method identifiers and field identifiers reduces the number of expensive remote calls to Java virtual machine 202 from remote execution container 204. The method identifiers and field identifiers do not change over the lifetime of a loaded class. The method identifiers and field identifiers are valid across all threads within Java virtual machine 202 as opposed to being only thread-local. Integration with class loading technology within Java virtual machine 202 enables cached field identifiers and method identifiers to only remain in the cache while useful.
[0042] Applying this technique enables subsequent call 222 for the field identifier or method identifier to be resolved using cache 206. Response 224 resolves subsequent call 222 through lookup of the unique identifier from table 214 and then locates the requested information in one of collection 208, collection 210 or collection 212. Subsequent remote calls to Java virtual machine 202 to retrieve a field identifier or method identifier are eliminated thereby reducing the number of expensive remote calls to 1 from N when the field identifier or method identifier is used N times, thus eliminating N-1 round trips. Rather than making one call for the class lookup and one call for the use of the field identifier or the method identifier to Java virtual machine 202, after the initial call only remote execution container 204 call for the use of the field or method is needed.
[0043] When a class is no longer needed an unsolicited class unload notice 226 may be sent from Java virtual machine 202 to remote execution container 204 to free storage in cache 206. In another operation, when local references are no longer required, remote execution container 204 may perform a delete local reference request 228 to remove references that are no longer useful from table 214.
[0044] With reference to Figure 3, a block diagram of a cache data structure of the remote execution container of Figure 2 is presented in accordance with one embodiment of the disclosure. Cache data structure 300 is an example of cache 206 of Figure 2.
[0045] Table 302 is an example of table 214 of Figure 2 containing local reference ID1 310, unique class ID 1 312, local reference IDn 314 and unique class IDn 316. A
unique class identifier, such as unique class ID 1 312, is used as a key or pointer 318 into a subset of the cache, such as collection 304, that holds field and method identifiers for the particular class.
Collection 304 removes the need for repeatedly accessing information available in Java virtual machine 202 of Figure 2 through the class identifier but which is otherwise not previously available to the native of remote execution container 204 of Figure 2 when executing remotely.
Unique class IDn 316 is used as a key or pointer 320 into a subset of the cache, such as collection 306 in a similar manner. The unique class identifier is used to add and obtain field identifiers and method identifiers from cache 300.
[0046] The initial request using the application programming interface for a field or method identifier will make the required remote call from remote execution container 204 of Figure 2 to get the field identifier or method identifier from Java virtual machine 202 of Figure 2. The remote execution container will populate one of collection 304, or collection 306 or collection 308 of cache 300, or create a new container as required and return the identifier as requested to the caller. Subsequent requests for the field identifier or method identifier, whether from the same thread or a different thread because field identifiers and method identifiers are valid across threads, will locate a copy of a requested identifier within cache 300 and return the field or method identifier without requiring an expensive remote call to Java virtual machine 202 of Figure 2. Through this technique the expensive remote call for all but the first request to lookup a method identifier or field identifier is resolved at the remote execution container.
[0047] A jclass (the identifier for a class) returned to the Java Native Interface method is a local reference that is only valid for the lifespan of the invocation of that method. Different invocations of a Java Native Interface method or invocations of different Java Native Interface methods to lookup field or method identifiers for a particular class pass a different jclass to the method than the jclass from previous invocations. Therefore the value of the jclass passed in cannot be used as the key or pointer directly in the cache.
[0048] In a typical virtual machine the current value of the jclass can be converted to a unique value representing the actual class. However in a split virtual machine, doing the same thing would require an expensive remote call back to the Java virtual machine.
[0049] In an embodiment of the disclosed enhanced Java process a determination is made as to whether a given jobject is a jclass or not. When passing a jobject, which is a jclass to a remote execution container, a unique value, such as unique class ID1 312 is sent along with local reference ID 1 310. Unique class ID 1 312 can either be derived from a constant known value that already exists given an particular implementation of the Java virtual machine or be provided by extending fields within java.lang.Class to hold a unique value for every class.
[0050] In the remote execution container, such as remote execution container 204 of Figure 2, the additional unique class value is placed into a data structure such as table 214 enabling the unique class value to be obtained given the corresponding local reference. An entry from the data structure will be removed either when a corresponding local reference is deleted through a call, such as, DeleteLocalRef or when the native to which the local reference was passed terminates. In this way the additional inforrnation and the associated storage will only be retained while a possible use remains.
[0051] When a request to lookup a field or method identifier is received, local reference such as local reference ID1 310, is used to lookup the corresponding unique value such as unique class ID 1 312 for the jclass. The unique value is used to perform a lookup for an entry and an add operation of an entry using cache 300 when necessary.
[0052] With reference to Figure 4, a block diagram of a system of multiple remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure is presented. System 400 is an example of system 200 of Figure 2 with two remote execution containers in use.
[0053] Cache management ensures the cache does not grow without bound and the entries contained within are always valid. Cache management removes entries for classes, which are no longer valid. Cache management is performed in a way that does not require an expensive remote call for each field identifier or method identifier request. Field identifiers and method identifiers remain valid at most until the associated class is unloaded in the Java virtual machine.
[0054] In an example, Java virtual machine 402 creates an unsolicited class unload event sent from garbage collector 404 as event notice 410 and event notice 412 to remote execution container 1 406 and remote execution container N 408 in which methods and fields have been cached.
[0055] Since fields and methods may be looked up and used many times over the lifetime of a class the net number of remote calls will be reduced. This base approach can be further optimized using one, or any combination of the following techniques. For example, maintaining a unique identifier for a classloader associated with each class for which field identifiers and method identifiers in the cache. Garbage collector 404 sends a single classloader unload event, such as event 410, when a classloader is unloaded, to remove the entries for all classes loaded by that classloader with only a single remote call. Unloading a classloader typically triggers unloading many associated classes.
[0056] In another example, when performing a look up of method identifiers and field identifiers for the first time a remote call, that obtains the field identifier or the method identifier, also registers the issuing remote native execution container, such as remote execution container N
408, is interested in unload events for the specific class and or classloader.
Garbage collector 404 only sends unload events to remote execution container 404 that cached methods or fields for the class.
[0057] In another example, batching unload calls from garbage collector 404 enables sending the unload message when a number of classes unloaded reaches a predetermined threshold value.
The unload messages may be sent for all such classes in a single unsolicited remote call.
[0058] In another example, an initial remote call for a new field or method is expanded to enable a returned result to provide additional information on which classes can be removed from the cache. The addition of the information reduces or eliminates the unsolicited class unload events.
Class unload information may also be compressed before transmission to reduce overhead.
Typical cache aging and least recently used techniques may also be used to remove entries from the cache.
[0059] The example of system 400 provides for each remote execution container to have an associated cache. In a variation, the cache of a set of remote execution containers may be shared across multiple remote execution containers on the same machine.
[0060] With reference to Figure 5, a flowchart of a process using the remote execution containers with cache data structures of Figure 2, in accordance with one embodiment of the disclosure. Process 500 is an example of using system 200 of Figure 2 for remote identifier caching to reduce the frequency of remote calls when using remote execution containers with a Java virtual machine.
[0061] Process 500 depicts a flow of operations after the initial exchange of class information has occurred. Populating a cache includes adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier. In one illustrative embodiment, the correspondence entry may be contained within a table. Other implementation examples to manage the pairing of unique class identifier and a local reference identifier suitable for performing a lookup may be used.
[0062] There cannot be a case were there is not a local identifier to class unique correspondence mapping. Because when the Java virtual machine sends the native (remote execution container) a local identifier for the class the Java virtual machine will also send the class unique identifier. In this way any time the native makes a request with the local identifier, there will already be a corresponding local identifier to class unique correspondence mapping in the table managed by the remote execution container.
[0063] Process 500 begins (step 502) and receives a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier (step 504). Process 500 maps the local class identifier in the requested identifier to the unique identifier for the class (step 506). Process 500 determines, using the previously mapped unique class identifier, whether the requested identifier is in a cache (step 508).
The cache may be associated with one or more remote execution containers. When a determination is made that the requested identifier is in the cache, a "yes" result is obtained. When a determination is made that the requested identifier is not in the cache, a "no" result is obtained.
[0064] When a "no" result is obtained in step 508, process 500 sends the request to an enhanced Java virtual machine (step 510). The enhanced Java virtual machine includes an enhanced implementation of Java Native Interface. Process 500 receives a response identifier including a field identifier or a method identifier from the Java virtual machine (step 512).
[0065] Process 500 populates a cache with the response identifier using the previously mapped unique class identifier (step 514). Populating the cache creates data structures for a collection in which each collection includes a unique class identifier and an associated set of field identifiers and method identifiers. The set of field identifiers and method identifiers includes one or more entries of field identifiers and method identifiers or field identifiers or method identifiers as required.
[0066] Process 500 returns the requested identifier to a requester (step 516), terminating thereafter (step 518). The requested identifier may be returned from the cache after the cache is populated or before the population operation is completed.
When a "yes" result is obtained in step 508, process 500 obtains the requested identifier from the cache (step 520). Process 500 returns the requested identifier to a requester as before (step 516), terminating thereafter (step 518). Returning the requested identifier from the cache to a requester may further comprise determining whether the response identifier is needed in the cache and responsive to a determination that the response identifier is not needed in the cache, removing selected entries from the cache [0067] Thus is described in one embodiment, a computer-implemented process for remote caching of an identifier is executed in a distributed Java virtual machine in which a Java Native Interface implementation has been enhanced to send an additional unique class identifier to a remote execution container for each invocation specific class identifier exchanged with the Java virtual machine. The remote execution container further keeps a table of pairings of invocation specific/unique identifiers, receives a request for a field or method identifier associated with a particular class, given a local identifier for the particular class specified, to form a requested identifier, maps the local identifier for the particular class included in the request to a unique class identifier using the table maintained by the remote execution container, determines using the previously mapped unique class identifier, whether the requested identifier is in a cache.
Responsive to a determination that the identifier is not in the cache the request is sent to the Java virtual machine. The computer-implemented process receives a response identifier including a field identifier or a method identifier from the Java virtual machine, populates the cache with the response identifier using the previously mapped unique class identifier and returns the requested identifier to a requester. The enhancement to the Java virtual machine and remote execution container provides a capability to send a local/unique identifier for each jobject which is a class, either through invocation of Java Native Interface methods or when a Java Native Interface callback is made.
[0068] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the block might occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
[0069] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.
The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed.
Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
[00100]The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, and other software media that may be recognized by one skilled in the art.
[00101]It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
[00102]A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[00103]Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening UO controllers.
[00104]Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.
[00105]The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (20)
What is claimed is:
1. A computer-implemented process for remote caching of an identifier, the computer-implemented process comprising:
receiving a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
mapping the local identifier for the particular class in the requested identifier to a unique class identifier;
determining using the previously mapped unique class identifier whether the requested identifier is in a cache;
responsive to a determination that the requested identifier is not in the cache, sending the request to a virtual machine;
receiving a response identifier including an identifier from the virtual machine;
populating the cache with the response identifier using the previously mapped unique class identifier; and returning the requested identifier to a requester.
receiving a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
mapping the local identifier for the particular class in the requested identifier to a unique class identifier;
determining using the previously mapped unique class identifier whether the requested identifier is in a cache;
responsive to a determination that the requested identifier is not in the cache, sending the request to a virtual machine;
receiving a response identifier including an identifier from the virtual machine;
populating the cache with the response identifier using the previously mapped unique class identifier; and returning the requested identifier to a requester.
2. The computer-implemented process of claim 1 wherein the requested identifier is an identifier comprising one of a field identifier or a method identifier and wherein the virtual machine is an enhanced virtual machine sending local identifier and unique identifier pairs for all jobjects determined to be classes when the jobjects are passed to the requester in the invocation of a native or in a response to a Java Native Interface callback.
3. The computer-implemented process of claim 1 wherein responsive to a determination that the requested identifier is in the cache, comprises obtaining the requested identifier from the cache.
4. The computer-implemented process of claim 1 wherein populating the cache with the response identifier using the previously mapped unique class identifier further comprises:
adding a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
adding a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
5. The computer-implemented process of claim 1 populating the cache with the response identifier using the previously mapped unique class identifier further comprises:
adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
6. The computer-implemented process of claim 1 wherein returning the requested identifier from the cache to a requester further comprises:
determining whether the response identifier is needed in the cache; and responsive to a determination that the response identifier is not needed in the cache, removing selected entries from the cache.
determining whether the response identifier is needed in the cache; and responsive to a determination that the response identifier is not needed in the cache, removing selected entries from the cache.
7. The computer-implemented process of claim 1 wherein the cache is a shared cache among a set of remote execution containers.
8. A computer program product for remote caching of an identifier, the computer program product comprising:
a computer recordable-type media containing computer executable program code stored thereon, the computer executable program code comprising:
computer executable program code for receiving a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
computer executable program code for mapping the local identifier for the particular class in the requested identifier to a unique class identifier;
computer executable program code for determining using the previously mapped unique class identifier whether the requested identifier is in a cache;
computer executable program code responsive to a determination that the requested identifier is not in the cache, for sending the request to a virtual machine;
computer executable program code for receiving a response identifier including an identifier from the virtual machine;
computer executable program code for populating the cache with the response identifier using the previously mapped unique class identifier; and computer executable program code for returning the requested identifier to a requester.
a computer recordable-type media containing computer executable program code stored thereon, the computer executable program code comprising:
computer executable program code for receiving a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
computer executable program code for mapping the local identifier for the particular class in the requested identifier to a unique class identifier;
computer executable program code for determining using the previously mapped unique class identifier whether the requested identifier is in a cache;
computer executable program code responsive to a determination that the requested identifier is not in the cache, for sending the request to a virtual machine;
computer executable program code for receiving a response identifier including an identifier from the virtual machine;
computer executable program code for populating the cache with the response identifier using the previously mapped unique class identifier; and computer executable program code for returning the requested identifier to a requester.
9. The computer program product of claim 8 wherein the requested identifier is an identifier comprising one of a field identifier or a method identifier and wherein the virtual machine is an enhanced virtual machine sending local identifier and unique identifier pairs for all jobjects determined to be classes when the jobjects are passed to the requester in the invocation of a native or in a response to a Java Native Interface callback.
10. The computer program product of claim 8 wherein computer executable program code responsive to a determination that the requested identifier is in the cache, further comprises computer executable program code for obtaining the requested identifier from the cache.
11. The computer program product of claim 8 wherein computer executable program code for populating the cache with the response identifier using the previously mapped unique class identifier further comprises:
computer executable program code for adding a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
computer executable program code for adding a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
12. The computer program product of claim 8 wherein computer executable program code for populating the cache with the response identifier using the previously mapped unique class identifier further comprises:
computer executable program code for adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
computer executable program code for adding a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
13. The computer program product of claim 8 wherein computer executable program code for returning the requested identifier from the cache to a requester further comprises:
computer executable program code for determining whether the response identifier is needed in the cache; and computer executable program code responsive to a determination that the response identifier is not needed in the cache, for removing selected entries from the cache.
computer executable program code for determining whether the response identifier is needed in the cache; and computer executable program code responsive to a determination that the response identifier is not needed in the cache, for removing selected entries from the cache.
14. The computer program product of claim 8 wherein the cache is a shared cache among a set of remote execution containers.
15. An apparatus for remote caching of an identifier, the apparatus comprising:
a communications fabric;
a memory connected to the communications fabric, wherein the memory contains computer executable program code;
a communications unit connected to the communications fabric;
an input/output unit connected to the communications fabric;
a display connected to the communications fabric; and a processor unit connected to the communications fabric, wherein the processor unit executes the computer executable program code to direct the apparatus to:
receive a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
map the local identifier for the particular class in the requested identifier to a unique class identifier;
determine using the previously mapped unique class identifier whether the requested identifier is in a cache;
responsive to a determination that the requested identifier is not in the cache, send the request to a virtual machine;
receive a response identifier including an identifier from the virtual machine;
populate the cache with the response identifier using the previously mapped unique class identifier; and return the requested identifier to a requester.
a communications fabric;
a memory connected to the communications fabric, wherein the memory contains computer executable program code;
a communications unit connected to the communications fabric;
an input/output unit connected to the communications fabric;
a display connected to the communications fabric; and a processor unit connected to the communications fabric, wherein the processor unit executes the computer executable program code to direct the apparatus to:
receive a request for an identifier associated with a particular class given a local identifier for the particular class to form a requested identifier;
map the local identifier for the particular class in the requested identifier to a unique class identifier;
determine using the previously mapped unique class identifier whether the requested identifier is in a cache;
responsive to a determination that the requested identifier is not in the cache, send the request to a virtual machine;
receive a response identifier including an identifier from the virtual machine;
populate the cache with the response identifier using the previously mapped unique class identifier; and return the requested identifier to a requester.
16. The apparatus of claim 15 wherein the requested identifier is an identifier comprising one of a field identifier or a method identifier and wherein the virtual machine is an enhanced virtual machine sending local/unique identifier pairs for all jobjects determined to be classes when the jobjects are passed to the requester in the invocation of a native or in a response to a Java Native Interface callback.
17. The apparatus of claim 15 wherein the processor unit further executes the computer executable program code responsive to a determination that the requested identifier is in the cache, to direct the apparatus to:
obtain the requested identifier from the cache.
obtain the requested identifier from the cache.
18. The apparatus of claim 15 wherein the processor unit further executes the computer executable program code to populate the cache with the response identifier using the previously mapped unique class identifier directs the apparatus to:
add a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
add a collection to the cache wherein the collection comprises a unique class identifier and a set of field identifiers and method identifiers associated with the unique class identifier.
19. The apparatus of claim 15 wherein the processor unit further executes the computer executable program code to populate the cache with the response identifier using the previously mapped unique class identifier further directs the apparatus to:
add a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
add a correspondence entry to the cache, wherein the correspondence entry comprises the unique class identifier and a local reference identifier corresponding to the unique class identifier.
20. The apparatus of claim 15 wherein the processor unit further executes the computer executable program code to return the requested identifier from the cache to a requester further directs the apparatus to:
determine whether the response identifier is needed in the cache; and responsive to a determination that the response identifier is not needed in the cache, remove selected entries from the cache.
determine whether the response identifier is needed in the cache; and responsive to a determination that the response identifier is not needed in the cache, remove selected entries from the cache.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2701503A CA2701503A1 (en) | 2010-04-30 | 2010-04-30 | Remote caching of an identifier |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2701503A CA2701503A1 (en) | 2010-04-30 | 2010-04-30 | Remote caching of an identifier |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2701503A1 true CA2701503A1 (en) | 2010-07-21 |
Family
ID=42352594
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2701503A Abandoned CA2701503A1 (en) | 2010-04-30 | 2010-04-30 | Remote caching of an identifier |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2701503A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9195496B2 (en) | 2011-12-06 | 2015-11-24 | International Business Machines Corporation | Automated caching and mirroring of immutable data in distributed virtual machines via native interface components |
-
2010
- 2010-04-30 CA CA2701503A patent/CA2701503A1/en not_active Abandoned
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9195496B2 (en) | 2011-12-06 | 2015-11-24 | International Business Machines Corporation | Automated caching and mirroring of immutable data in distributed virtual machines via native interface components |
| GB2511968B (en) * | 2011-12-06 | 2016-09-07 | Ibm | Hidden automated data mirroring for native interfaces in distributed virtual machines |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10324734B2 (en) | Application containers | |
| US6611898B1 (en) | Object-oriented cache management system and method | |
| US11099937B2 (en) | Implementing clone snapshots in a distributed storage system | |
| EP1677201B1 (en) | Common cache management in a plurality of virtual machines | |
| US8375379B2 (en) | Importing language extension resources to support application execution | |
| EP1805630B1 (en) | Cache eviction | |
| US7418560B2 (en) | Centralized cache storage for runtime systems | |
| US8972690B2 (en) | Methods and apparatuses for usage based allocation block size tuning | |
| US7689660B2 (en) | Application server architecture | |
| CN100580633C (en) | A method of maintaining applications in a computing device | |
| US20120130963A1 (en) | User defined function database processing | |
| US20150269075A1 (en) | Cache region concept | |
| US6976065B2 (en) | Mechanism for reconfiguring a server without incurring server down time | |
| US20100223305A1 (en) | Infrastructure for spilling pages to a persistent store | |
| US8984530B2 (en) | Queued message dispatch | |
| KR100747466B1 (en) | A device management client and device management method using nodes having additional properties | |
| EP3283965B1 (en) | Reducing memory commit charge when compressing memory | |
| US9361224B2 (en) | Non-intrusive storage of garbage collector-specific management data | |
| CN102880557A (en) | Multistage distribution type high-speed cache of heterogeneous data source | |
| EP3365798B1 (en) | System and method for providing distributed caching in transactional processing environment | |
| US7752625B2 (en) | Caching resources requested by applications | |
| US20120151110A1 (en) | Process-safe read/write locks | |
| US10635715B2 (en) | Remote virtualized asset delivery and local provisioning | |
| CN111090823B (en) | Page application integration system, application access method, device and equipment | |
| CN106095817A (en) | Extensible file system based on micro-kernel and file access method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |
Effective date: 20130408 |
|
| FZDE | Discontinued |
Effective date: 20130408 |