Abstract: A method, system, and computer program product to dynamically determine the applicability of a hardware accelerator to a request for a function, the request including a set of blocks of input data, are described. Aspects include storing a decision of whether to use the hardware accelerator or a software module to execute the function based on a previously processed request and determining whether the request matches the previously processed request. Aspects also include processing the set of blocks of input data using the hardware accelerator or the software module according to the decision based on the request matching the previously processed request.

Abstract: A method, system, and computer program product to dynamically determine the applicability of a hardware accelerator to a request for a function, the request including a set of blocks of input data, are described. Aspects include storing a decision of whether to use the hardware accelerator or a software module to execute the function based on a previously processed request and determining whether the request matches the previously processed request. Aspects also include processing the set of blocks of input data using the hardware accelerator or the software module according to the decision based on the request matching the previously processed request.

Abstract: Methods and systems may track the invocation path of a system or a library call from Java native interface (JNI) in Java applications. A native call of interest having an associated failure condition, an invocation path associated with the native call of interest, and a Java boundary crossover method (Java method invoking a JNI method) within the invocation path may all identified based on failure diagnostic information. The identified information may also be fed to a Java virtual machine (JVM). When the application is re-run, a check can be made prior to execution of the JNI method, as to whether the Java boundary crossover method is being executed. If so, then the execution stack may be compared to the invocation path of interest.

Abstract: Methods and systems may track the invocation path of a system or a library call from Java native interface (JNI) in Java applications. A native call of interest having an associated failure condition, an invocation path associated with the native call of interest, and a Java boundary crossover method (Java method invoking a JNI method) within the invocation path may all identified based on failure diagnostic information. The identified information may also be fed to a Java virtual machine (JVM). When the application is re-run, a check can be made prior to execution of the JNI method, as to whether the Java boundary crossover method is being executed. If so, then the execution stack may be compared to the invocation path of interest.

Abstract: A method, system and computer program product for generating appropriately sized core files used in diagnosing application crashes. An instruction pointer corresponding to the instruction that led to the application crash is identified. Address ranges of the garbage collection module and the compiler module are obtained. A determination is made as to whether the address of the instruction pointer lies within any of these address ranges for each stack frame in a crash stack. If it does not, then read or write instructions executed prior to the instruction that led to the application crash are identified for each stack frame in the crash stack. If a value of a register involved in such read or write instructions is within the address range of the compiled code buffers and/or heap, then the compiled code buffers and/or heap need to be included in the core file; otherwise, they do not.

Abstract: A Java object is scan-missed during the mark phase of a garbage collection cycle. A list of any unscanned objects, comprising all objects of a particular object type, is created during a sweep phase of the garbage collection cycle. After the garbage collection cycle is completed, and the application resumes, for every PUTFIELD/GETFIELD operation on the object type that is part of a specific parent object, a comparison is made with the relevant information in the unscanned objects list. A scan-miss is identified by determining whether the current object being referenced by the application is a part of the unscanned object list that has been created during the sweep phase of the garbage collection cycle.

Abstract: A method, system and computer program product for generating appropriately sized core files used in diagnosing application crashes. An instruction pointer corresponding to the instruction that led to the application crash is identified. Address ranges of the garbage collection module and the compiler module are obtained. A determination is made as to whether the address of the instruction pointer lies within any of these address ranges for each stack frame in a crash stack. If it does not, then read or write instructions executed prior to the instruction that led to the application crash are identified for each stack frame in the crash stack. If a value of a register involved in such read or write instructions is within the address range of the compiled code buffers and/or heap, then the compiled code buffers and/or heap need to be included in the core file; otherwise, they do not.

Abstract: A Java object is scan-missed during the mark phase of a garbage collection cycle. A list of any unscanned objects, comprising all objects of a particular object type, is created during a sweep phase of the garbage collection cycle. After the garbage collection cycle is completed, and the application resumes, for every PUTFIELD/GETFIELD operation on the object type that is part of a specific parent object, a comparison is made with the relevant information in the unscanned objects list. A scan-miss is identified by determining whether the current object being referenced by the application is a part of the unscanned object list that has been created during the sweep phase of the garbage collection cycle.