Browse Prior Art Database

Descriptive Tracing of Java Field Values Using Stored Trees of Operand/Operator Descriptions

IP.com Disclosure Number: IPCOM000016203D
Original Publication Date: 2002-Sep-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 51K

Publishing Venue

IBM

Abstract

Tracing is traditionally based on tracepoints pinpointing code location.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 3

  Descriptive Tracing of Java Field Values Using Stored Trees of Operand/Operator Descriptions

Tracing is traditionally based on tracepoints pinpointing code location.

     Disclosed here is tracing based on dataflow analysis, recording the operations that led towards an actual data value. This addresses is tracing why an incorrect java program result is being reached. Tracing why some Java* data value is incorrect is often difficult as:

a) One has to work out all the functions that relate to the value

b) One as to trace the values that fed in to them and where they came from recursively to form the 'transitive closure' - ie the data 'tributaries' and the processing that led to the result. c) within each method one has to verify that the algorithm/function applied is correct.

The stack based Java Virtual Machine provides the foundation for a much smarter mechanism to solve this problem. In Java, operands are exchanged via the Java stack, for example a JVM multiply instruction will take the top two items on the stack and replace those with the product. By recursively parsing an instruction trace file one can follow back all the operations that feed into a data item being produced on the Java stack or in the field table of a Java object. Working forwards, by associating descriptions for the foundation base data with the data and having description "operators" that operate on the descriptions one can build a full history of a data items inputs. This description can be human readable and followed by a human (or have assertions applied to operation/function inputs and outputs) after the fact. The description can be output to aid a user trace back why a value is incorrect, it will provide the equivalent of a trace log file but aimed at how data values got to where they are rather than how threads got to where they are. It can be produced without any alteration of the Java source. If desired this description could be composed of tracepoint or method identifiers that were relevant to a variable's final value and be output and processed in such a way as to build a trace properties file that could pinpoint conventional trace. The method associates data descriptions with atomic values that form the foundation of calculations and has operators on these descriptions analogous to the data operators. As the data is stored on the operand stack and in java fields the descriptions will be likewise stored. It will be possible to access the description for a given field or stack item's current value. This description will provide the tree of operations that led to the data value being what it is. For the sake of illustration of Java bytecode, imagine we wish to trace the computation that resulted in the value of X being computed as 20 in java. At some point in the program we will have X = 20; bipush 20; putstatic <classname> X I; or more likely
X = X + 5; getstatic <classname> X I; iconst_5; iadd; putstatic <classname> X I;

1

Page 2 of 3

or X = J + K; getsta...