Patent application number | Description | Published |
20090307667 | ASSISTING DEBUG MEMORY TRACING USING AN INSTRUCTION ARRAY THAT TRACKS THE ADDRESSES OF INSTRUCTIONS MODIFYING USER SPECIFIED OBJECTS - 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. | 12-10-2009 |
20100095278 | TRACING A CALLTREE OF A SPECIFIED ROOT METHOD - 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. | 04-15-2010 |
20110231814 | IDENTIFYING LOCK GRANULARIZATION OPPORTUNITIES - 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. | 09-22-2011 |
20120158801 | DETERMINING WHETHER A JAVA OBJECT HAS BEEN SCAN-MISSED BY A GARBAGE COLLECTOR SCAN - 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. | 06-21-2012 |
20120304015 | GENERATING APPROPRIATELY SIZED CORE FILES USED IN DIAGNOSING APPLICATION CRASHES - 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. | 11-29-2012 |
20130318058 | MANAGEMENT OF LONG-RUNNING LOCKS AND TRANSACTIONS ON DATABASE TABLES - 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. | 11-28-2013 |
20140122939 | Tracking Specific JAVA Native Interface Invocations of System and Library Calls - 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. | 05-01-2014 |
20150213050 | MANAGEMENT OF LONG-RUNNING LOCKS AND TRANSACTIONS ON DATABASE TABLES - 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 reacqusition of each of the pair of overlapping shared locks on the outer database ownership table and the inner database ownership table is alternated. | 07-30-2015 |