Abstract: Aspects of the invention include systems and methods configured to checkpoint an application executing on a virtual machine. Aspects include receiving from a first thread executing on a virtual machine a call to a checkpoint application program interface (API) and suspending, by the virtual machine, execution of all threads other than the first thread. Aspects also includes executing, by the virtual machine, all application checkpoint hooks and executing, by the virtual machine, all virtual machine checkpoint hooks. Aspects further include creating one or more checkpoint image files.

Abstract: Systems and methods are described for improving portability of checkpoints of an application using central processing unit (CPU)-specific features. In an example, a system includes a source computing system and a destination computing system. The source computing system may be configured to: cause a first execution of an application that includes a function associated with a plurality of implementations; receive a request to resolve an implementation decision for the function; select, based on a set of source CPU-specific features, a source-specific implementation for the first execution of the function; patch, by rendering a resolved callsite table, a call site associated with the function with an address of the source-specific implementation; and send, to a destination computing system, a checkpoint of the application that includes the resolved callsite table.

Abstract: Systems and methods are described for improving portability of virtual machine checkpoints without affecting system performance. In an example, a method includes determining, by a source computing system having a processor, via a virtual machine, and based on a runtime of an application on the virtual machine, one or more units of the application to compile as one or more non-portable units of the application; designating, as a non-entrant compiled code, the one or more non-portable units of the application, wherein the designation prevents execution of the one or more non-portable units; decompiling, by the source computing system, one or more stack frames associated with the one or more non-portable units of the application; sending, by the source computing system to a destination computing system, a checkpoint for the application; restoring, by the destination computing system via the virtual machine, from the checkpoint for the application, the runtime of the application.

Abstract: Systems and methods are described for improving portability of checkpoints of an application using central processing unit (CPU)-specific features. In an example, a system includes a source computing system and a destination computing system. The source computing system may be configured to: cause a first execution of an application that includes a function associated with a plurality of implementations; receive a request to resolve an implementation decision for the function; select, based on a set of source CPU-specific features, a source-specific implementation for the first execution of the function; patch, by rendering a resolved callsite table, a call site associated with the function with an address of the source-specific implementation; and send, to a destination computing system, a checkpoint of the application that includes the resolved callsite table.

Abstract: A computer-implemented method for bytecode class verification includes: encountering a class requiring verification of its bytecode during a run of an application; determining whether class relationship data for the class exists in a shared classes cache; in response to a determination that the class relationship data for the class does not exist in the shared classes cache: performing a linear bytecode walk of the bytecode to identify relationship data for the class and verify that the bytecode is well-formed; and storing the identified relationship data as the class relationship data for the class in the shared classes cache; in response to a determination that the class relationship data for the class does exist in the shared classes cache: retrieving the class relationship data for the class from the shared classes cache; and processing the class relationship data.

Abstract: A snapshot handler is registered with an event monitoring subsystem of a process virtual machine, the registering specifying a trigger event of the snapshot handler, wherein the trigger event comprises execution of a specified portion of an application executing in the process virtual machine, the trigger event specified externally from a source code of the application. Responsive to the event monitoring subsystem detecting an occurrence of the trigger event, the snapshot handler is executed, storing data of an execution state of the process virtual machine at a time of occurrence of the trigger event.

Abstract: A snapshot handler is registered with an event monitoring subsystem of a process virtual machine, the registering specifying a trigger event of the snapshot handler, wherein the trigger event comprises execution of a specified portion of an application executing in the process virtual machine, the trigger event specified externally from a source code of the application. Responsive to the event monitoring subsystem detecting an occurrence of the trigger event, the snapshot handler is executed, storing data of an execution state of the process virtual machine at a time of occurrence of the trigger event.

Abstract: A snapshot handler is registered with an event monitoring subsystem of a process virtual machine, the registering specifying a trigger event of the snapshot handler, wherein the trigger event comprises execution of a specified portion of an application executing in the process virtual machine, the trigger event specified externally from a source code of the application. Responsive to the event monitoring subsystem detecting an occurrence of the trigger event, the snapshot handler is executed, storing data of an execution state of the process virtual machine at a time of occurrence of the trigger event.

Abstract: A computer-implemented method for bytecode class verification includes: encountering a class requiring verification of its bytecode during a run of an application; determining whether class relationship data for the class exists in a shared classes cache; in response to a determination that the class relationship data for the class does not exist in the shared classes cache: performing a linear bytecode walk of the bytecode to identify relationship data for the class and verify that the bytecode is well-formed; and storing the identified relationship data as the class relationship data for the class in the shared classes cache; in response to a determination that the class relationship data for the class does exist in the shared classes cache: retrieving the class relationship data for the class from the shared classes cache; and processing the class relationship data.

Abstract: A computer-implemented method for bytecode class verification includes: encountering a class requiring verification of its bytecode during a run of an application; determining whether class relationship data for the class exists in a shared classes cache; in response to a determination that the class relationship data for the class does not exist in the shared classes cache: performing a linear bytecode walk of the bytecode to identify relationship data for the class and verify that the bytecode is well-formed; and storing the identified relationship data as the class relationship data for the class in the shared classes cache; in response to a determination that the class relationship data for the class does exist in the shared classes cache: retrieving the class relationship data for the class from the shared classes cache; and processing the class relationship data.

Abstract: A snapshot handler is registered with an event monitoring subsystem of a process virtual machine, the registering specifying a trigger event of the snapshot handler, wherein the trigger event comprises execution of a specified portion of an application executing in the process virtual machine, the trigger event specified externally from a source code of the application. Responsive to the event monitoring subsystem detecting an occurrence of the trigger event, the snapshot handler is executed, storing data of an execution state of the process virtual machine at a time of occurrence of the trigger event.

Abstract: An embodiment includes requesting, by a compiler responsive to execution of a first code segment, a first profile dataset associated with the first code segment. The embodiment also includes executing, responsive to receiving an indication that the first profile dataset is not available, a querying process that searches other code segments based on specified criteria relating to an attribute of the first code segment. The embodiment also includes receiving a search result from the querying process, where the search result includes a second code segment. The embodiment also includes generating an extrapolated profile dataset based at least in part on the second code segment. The embodiment stores the extrapolated profile dataset in memory associated with the first code segment, and the compiler performs an optimization process on the first code segment using the extrapolated profile dataset.

Abstract: Resolving segmented constant pools in a virtual machine managed runtime. An embodiment includes allocating, using one or more processors of a computing device, for each specialization created in a class of specializations, a constant pool (CP) cache, assigning an owner to each segment of constant pools, maintaining, in a memory of the computing device, a list of specializations in the class, and copying, upon determining that a CP segment entry visible to the specialization is resolved in the owner, the entry to a specializations cache of the memory. An embodiment includes assigning a new specialized CP segment as an owner of that CP segment and adding a new entry associated with the new specialization to a template class owners table, retrieving, based on looking for entry at runtime, a slot pointed to in the owners table and resolving the CP entry in the constant pool cache of the owner.

Abstract: Embodiments of the present invention comprise a class sharing orchestrator (CSO) operating as a subsystem of a container orchestrator. The CSO manages sharing of class data among containerized applications to improve startup performance, CPU consumption and memory footprint. The CSO stores application class data in a shared class cache (SCC). The CSO provides a compatible SCC to every deployed application running within the CSO's purview. The CSO collects SCC data from running applications, and processes the data offline to continuously improve the quality of SCCs provided to each deployment, while causing minimum impact to running applications. The CSO combines updates from running applications of a given type to generate an improved quality SCC for use by newly launched applications of the same type. The CSO comprises an SCC update mechanism that optimizes the size, and network traffic, associated with SCC data exchange, and guarantees SCC quality improves over time.

Abstract: An embodiment includes executing a code interpretation engine such that the interpretation engine interprets a first portion of a source code that includes a first comparison between a first pair of operands. The embodiment also includes performing, in memory, a first bitwise comparison between a block A1 and a block B1 of the first portion of the source code. The embodiment also speeds up execution of the first portion of the source code responsive to the first bitwise comparison producing a negative result. The embodiment speeds up the first portion by omitting at least one of (i) a second bitwise comparison between a block A2 and a block B2, and (ii) a field-wise comparison between a block A3 and a block B3.

Abstract: A method list is built for a currently executing application within a process virtual machine at a snapshot point, the method list comprising a set of methods capable of being executed by the currently executing application after the snapshot point, the snapshot point comprising an execution state of the currently executing application when a snapshot process is triggered. Profiling data of the currently executing application, collected prior to reaching the snapshot point, is committed, to a designated storage location. Using the profiling data and a just-in-time compiler of the process virtual machine, a method in the method list is compiled. Snapshot data comprising data of the execution state of the currently executing application at the snapshot point, including a result of the compiling, is stored.

Abstract: Optimizing containerized applications includes receiving managed runtime code, creating a first container within a managed runtime environment, and executing the managed runtime code in the first container within the managed runtime environment. Responsive to a determination that the managed runtime environment has performed at least one optimization of the managed runtime code to create optimized managed runtime code during a first lifetime of the managed runtime environment, the first container is checkpointed into a first memory image to create a first checkpointed container including the optimized managed runtime code. The first checkpointed container is stored.

Abstract: During verification of a bytecode, when a second class remains to be loaded for verification in an MRE, a verifier in the MRE is prevented from loading the second class, where the bytecode includes a relationship between a first class and the second class. The relationship is recorded and the verifier is caused to omit a loading operation on the second class. An execution is started of an application encoded in the bytecode. The second class is caused to be loaded and verified prior to a use of the second class during the execution.

Abstract: A computerized operating system begins a garbage-collection operation by collecting a set of “garbage” data objects to be deleted. Certain of these objects are identified, either by an embedded identifier or by an entry in a sensitive-objects data structure, as containing sensitive data. When the garbage collector moves or deletes a sensitive object during the garbage-collection procedure, the collector zeroes out any residual data left at the object's original location in memory or secondary storage. If the collector determines that the object no longer has any connection to other software entities, the collector zeroes out the storage locations of all identified instances of the object. The collector then updates the data structure to indicate the current location of sensitive objects that have been moved or copied, and deletes entries for zeroed out instances of deleted sensitive objects.

Abstract: An embodiment includes executing a code interpretation engine such that the interpretation engine interprets a first portion of a source code that includes a first comparison between a first pair of operands. The embodiment also includes performing, in memory, a first bitwise comparison between a block A1 and a block B1 of the first portion of the source code. The embodiment also speeds up execution of the first portion of the source code responsive to the first bitwise comparison producing a negative result. The embodiment speeds up the first portion by omitting at least one of (i) a second bitwise comparison between a block A2 and a block B2, and (ii) a field-wise comparison between a block A3 and a block B3.