International Business Machines Corporation

Venkataraghavan Lakshminarayanachar

Lohitashwa Thyagaraj

Rajesh C Lalgowdar

Justin T Fries

Prashanth K Nageshappa

Amar Devegowda

Prasanna K Kalle

Douglas J Griffith

James Edward Fox

Sathiskumar Palaniappan

Anshu Verma

Charles Robert Gracie

Aruna A Kalagananam

Alan Edward Booth

Release and re-acquisition of each of a first shared lock on an outer database ownership table and a second shared lock on an inner database ownership table is alternated by a messaging engine processor that executes a messaging engine to permit database maintenance operations to be performed while maintaining the ownership of the database. At least one period of inactivity of both the outer database ownership table and the inner database ownership table is provided that allows at least one database tool to execute to perform at least one database maintenance task during the execution of the messaging engine.

Management of long-running locks and transactions on database tables

An exclusive lock is acquired on each of an outer database ownership table and an inner database ownership table to obtain ownership of a database. The exclusive locks are converted to a pair of overlapping shared locks on each of the outer database ownership table and the inner database ownership table, where release and re-acquisition of each of the pair of overlapping shared locks on the outer database ownership table and the inner database ownership table permits database maintenance operations to be performed while maintaining the ownership of the database.

Establishment of an exclusive lock on each of an outer database ownership table and an inner database ownership table is attempted. In response to establishing the exclusive lock on each of the outer database ownership table and the inner database ownership table, a switch is made to a pair of overlapping shared locks on each of the outer database ownership table and the inner database ownership table. Release and re-acquisition of each of the pair of overlapping shared locks on the outer database ownership table and the inner database ownership table is alternated.

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.

Tracking specific Java native interface invocations of system and library calls

Embodiments of the invention broadly contemplate systems, methods, apparatuses and program products providing a mechanism in a run-time environment or Virtual Machine (VM) which enables a user to specify the combination of method(s) and thread(s) the user wants to collect traces for, without having to make any modifications to the application source code.

Systems and methods for virtual machine thread tracing

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.

Generating appropriately sized core files used in diagnosing application crashes

Lock granularization opportunities are identified in computer code. A processor is used to generate synchronized code blocks and fields (data) accessed in each code block. Each of the code blocks can then be represented by a set. A list of non-intersecting synchronized code blocks having no commonly accessed fields is generated, and a list of intersecting synchronized code blocks (code blocks each having at least one commonly accessed field) is also generated. Equal and superset-subset lists are then generated from the list of intersecting synchronized code blocks. Granularized locks are applied directly around the fields that are accessed within code blocks represented by non-intersecting and equal sets. Granularized locks are also applied around the fields that are accessed within code blocks represented by the superset, and the same locks are applied to code blocks represented by the subsets, thereof.

Identifying lock granularization opportunities

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.

Determining whether a Java object has been scan-missed by a garbage collector scan

A specification of a routine name of a root of a call tree and a specification of a desired depth of call tree tracing are obtained. Upon entering a given routine in a program, a determination is made whether the given routine is the root. Responsive to determining that the given one of the routines is the root, trace information for the routine forming the root is output. Furthermore, upon entering a given one of the routines called, directly or indirectly, by the routine forming the root, a determination is made whether the given one of the routines called, directly or indirectly, by the routine forming the root of the call tree is within the desired depth from the routine forming the root of the call tree; and if this is the case, trace information is output for given one of the routines called, directly or indirectly, by the routine forming the root of the call tree.

Tracing a calltree of a specified root method

The present invention discloses a solution for increasing the immediacy in determining a point of failure after an unexpected program termination. In the solution, a user determined object is identified by a user at compile time, where the identified object is one to be tracked. The compiler introduces executable code into the source code which is able to track modifications made to the object members during run-time. During execution, the address of each instruction modifying to the object is stored in an instruction pointer (IP) array associated with the tracked object. The IP array is continuously updated during program execution when an instruction modifies a member of the tracked object. When an unexpected program termination occurs, the instruction pointer array can be presented to a debugging agent to assist in determining the instruction causing the termination. The debugging agent can be a human agent, debugging software, report generation software, and the like.

Assisting debug memory tracing using an instruction array that tracks the addresses of instructions modifying user specified objects

Embodiments of the invention broadly contemplate systems, methods, apparatuses and program storage devices providing a mechanism in which a file system and copy command (or file transfer command) allows the start of a copy operation when a file is being copied to and allow the system to continue to read the file as and when it gets updated (appended with additional data), thus permitting automated simultaneous file transfer and copy operations.

Growing community of inventors

Bengaluru, India

Venkataraghavan Lakshminarayanachar