Abstract: Creating message files in a publication subscription computer system by: (i) receiving data corresponding to a first message; (ii) receiving a list of subscribers that subscribe to a topic of the first message; and (iii) creating a digital data file that includes a payload data and a consumption metadata. The payload data includes content data corresponding to the first message. The consumption metadata includes data relating to whether one or more subscribers of the list of subscribers will potentially consume the first message at a later period in time from the time of receiving the content data corresponding to the first message.

Abstract: A process for providing a simulated date and/or time to a time-sensitive application is disclosed herein. Such a process may include detecting the invocation of a time handler method configured to retrieve system time. Upon detecting the invocation, the contents of a call stack may be captured and analyzed to determine which requestor method initiated the invocation. The process may then determine whether the requestor method should receive a real or simulated system time. A real system time may be returned to the requestor method in the event it should receive the real system time. A simulated system time may be returned to the requestor method in the event it should receive the simulated system time. A corresponding apparatus and computer program product are also disclosed and claimed herein.

Abstract: A process for providing a simulated date and/or time to a time-sensitive application is disclosed herein. Such a process may include detecting the invocation of a time handler method configured to retrieve system time. Upon detecting the invocation, the contents of a call stack may be captured and analyzed to determine which requester method initiated the invocation. The process may then determine whether the requester method should receive a real or simulated system time. A real system time may be returned to the requester method in the event it should receive the real system time. A simulated system time may be returned to the requester method in the event it should receive the simulated system time. A corresponding apparatus and computer program product are also disclosed and claimed herein.

Abstract: A process for providing a simulated date and/or time to a time-sensitive application is disclosed herein. Such a process may include detecting the invocation of a time handler method configured to retrieve system time. Upon detecting the invocation, the contents of a call stack may be captured and analyzed to determine which requestor method initiated the invocation. The process may then determine whether the requestor method should receive a real or simulated system time. A real system time may be returned to the requestor method in the event it should receive the real system time. A simulated system time may be returned to the requestor method in the event it should receive the simulated system time. A corresponding apparatus and computer program product are also disclosed and claimed herein.

Abstract: Under the present invention, program code is examined (statically or dynamically) for characteristics indicative of a potential to generate multiple threads. If none are found, single threaded optimization(s) such as desynchronization, optimization of globals, etc., can be implemented. In addition, if the program code is later revealed to have the potential to generate multiple threads, the single threaded optimization(s) can be corrected to avoid incorrect execution.

Abstract: A method, apparatus, and computer instructions for referencing a constant pool. A determination is made as to whether a bytecode references the constant pool. A relative offset to the constant pool is identified for the bytecode, in response to the bytecode referencing the constant pool. The bytecode is then replaced with a new bytecode containing the relative offset. The relative offset is used to reference the constant pool.

Abstract: A runtime-resource management method, system, and product for managing resources available to application components in a portable device. The method, system, and product provide for loading one or more new application components into a portable device only if maximum runtime resources required by the one or more new application components are available in the portable device assuming loaded application components within the device are using the maximum runtime resources reserved by the loaded application components, reserving maximum runtime resources required by application components when application components are loaded into the portable device, and running loaded application components using only the runtime resources reserved for the loaded application components.

Abstract: A runtime-resource management method, system, and product for managing resources available to application components in a portable device. The method, system, and product provide for loading one or more new application components into a portable device only if maximum runtime resources required by the one or more new application components are available in the portable device assuming loaded application components within the device are using the maximum runtime resources reserved by the loaded application components, reserving maximum runtime resources required by application components when application components are loaded into the portable device, and running loaded application components using only the runtime resources reserved for the loaded application components.

Abstract: A computer implemented method, apparatus, and computer usable program code for profiling an application. Data is collected for analyzing performance of the application using a device driver for a profiler in an operating system kernel in response to the application executing in a virtual machine. Data is stored in a buffer. A report is generated containing the data from the buffer in response to an event in the virtual machine, wherein the application is profiled using the report. Collection of the data is halted in response to the application terminating execution in the virtual machine.

Abstract: A process for providing a simulated date and/or time to a time-sensitive application is disclosed herein. Such a process may include detecting the invocation of a time handler method configured to retrieve system time. Upon detecting the invocation, the contents of a call stack may be captured and analyzed to determine which requester method initiated the invocation. The process may then determine whether the requester method should receive a real or simulated system time. A real system time may be returned to the requester method in the event it should receive the real system time. A simulated system time may be returned to the requester method in the event it should receive the simulated system time. A corresponding apparatus and computer program product are also disclosed and claimed herein.

Abstract: A method, apparatus, and computer instructions for referencing a constant pool. A determination is made as to whether a bytecode references the constant pool. A relative offset to the constant pool is identified for the bytecode, in response to the bytecode referencing the constant pool. The bytecode is then replaced with a new bytecode containing the relative offset. The relative offset is used to reference the constant pool.

Abstract: Under the present invention, program code is examined (statically or dynamically) for characteristics indicative of a potential to generate multiple threads. If none are found, single threaded optimization(s) such as desynchronization, optimization of globals, etc., can be implemented. In addition, if the program code is later revealed to have the potential to generate multiple threads, the single threaded optimization(s) can be corrected to avoid incorrect execution.

Abstract: Under the present invention, program code is examined (statically or dynamically) for characteristics indicative of a potential to generate multiple threads. If none are found, single threaded optimization(s) such as desynchronization, optimization of globals, etc., can be implemented. In addition, if the program code is later revealed to have the potential to generate multiple threads, the single threaded optimization(s) can be corrected to avoid incorrect execution.

Abstract: A computer implemented method, apparatus, and computer usable program code for profiling an application. Data is collected for analyzing performance of the application using a device driver for a profiler in an operating system kernel in response to the application executing in a virtual machine. Data is stored in a buffer. A report is generated containing the data from the buffer in response to an event in the virtual machine, wherein the application is profiled using the report. Collection of the data is halted in response to the application terminating execution in the virtual machine.

Abstract: A method, apparatus, and computer instructions for referencing a constant pool. A determination is made as to whether a bytecode references the constant pool. A relative offset to the constant pool is identified for the bytecode, in response to the bytecode referencing the constant pool. The bytecode is then replaced with a new bytecode containing the relative offset. The relative offset is used to reference the constant pool.

Abstract: A runtime-resource management method, system, and product for managing resources available to application components in a portable device. The method, system, and product provide for loading one or more new application components into a portable device only if maximum runtime resources required by the one or more new application components are available in the portable device assuming loaded application components within the device are using the maximum runtime resources reserved by the loaded application components, reserving maximum runtime resources required by application components when application components are loaded into the portable device, and running loaded application components using only the runtime resources reserved for the loaded application components.

Abstract: Memory segments are allocated for a classloader to store class information, such as by selecting an allocation approach based on classloader type. In a first approach, in response to each request, a segment having a fixed size is allocated. In a second approach, in response to a first request, a first segment having a size equal to an amount of memory needed to store information related to the request is allocated. In response to a second request, a second segment having a second size is allocated, and in response to a third request, a third segment having a third size greater than the second size is allocated. In a third approach, in response to the first request, a first segment having a first size is allocated. In response to a second request, a second segment having a second size greater than the first size is allocated.

Abstract: A runtime-resource management method, system, and product for managing resources available to application components in a portable device. The method, system, and product provide for loading one or more new application components into a portable device only if maximum runtime resources required by the one or more new application components are available in the portable device assuming loaded application components within the device are using the maximum runtime resources reserved by the loaded application components, reserving maximum runtime resources required by application components when application components are loaded into the portable device, and running loaded application components using only the runtime resources reserved for the loaded application components.

Abstract: Memory segments are allocated for a classloader to store class information, such as by selecting an allocation approach based on classloader type. In a first approach, in response to each request, a segment having a fixed size is allocated. In a second approach, in response to a first request, a first segment having a size equal to an amount of memory needed to store information related to the request is allocated. In response to a second request, a second segment having a second size is allocated, and in response to a third request, a third segment having a third size greater than the second size is allocated. In a third approach, in response to the first request, a first segment having a first size is allocated. In response to a second request, a second segment having a second size greater than the first size is allocated.

Abstract: Virtual function calls in hybrid compiled and interpreted computer programming environments are carried out efficiently by dual virtual function tables. Each class object generated is provided with a compiled virtual function table and an interpreted virtual function table. Each table is symmetrically structured and contiguous with the class object. Calls from an interpreted function access the interpreted virtual function table. Entries in that table point to function data structures which provide for the interpretation of the called function, or for transfer to execution of a compiled version of the called function. Calls from a compiled function access the compiled virtual function table. Entries in the compiled virtual function table point to either executable code representing the called function, or to transition code for transition to the interpreter to interpret the called function.