US20030145309A1 - Probe description language - Google Patents

Probe description language Download PDF

Info

Publication number
US20030145309A1
US20030145309A1 US10/287,185 US28718502A US2003145309A1 US 20030145309 A1 US20030145309 A1 US 20030145309A1 US 28718502 A US28718502 A US 28718502A US 2003145309 A1 US2003145309 A1 US 2003145309A1
Authority
US
United States
Prior art keywords
user
language
probe
level language
programming language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/287,185
Inventor
Rajendra Inamdar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BEA Systems Inc
Original Assignee
BEA Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BEA Systems Inc filed Critical BEA Systems Inc
Priority to US10/287,185 priority Critical patent/US20030145309A1/en
Priority to PCT/US2003/001131 priority patent/WO2003062986A1/en
Assigned to BEA SYSTEMS, INC. reassignment BEA SYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INAMDAR, RAJENDRA
Assigned to BEA SYSTEMS, INC. reassignment BEA SYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INAMDAR, RAJENDRA
Publication of US20030145309A1 publication Critical patent/US20030145309A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3624Software debugging by performing operations on the source code, e.g. via a compiler
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • G06F11/364Software debugging by tracing the execution of the program tracing values on a bus

Definitions

  • the invention relates generally to inserting code into applications.
  • Inserting debugging or tracing code in the source code of a program or application can have certain drawbacks. If debugging code is inserted in several places throughout an application, the source code can become cluttered with debug logic. Also, a programmer will have to anticipate the correct places to put the debug code when inserting it into the application. Once compiled, such debugging code cannot be changed. This can be undesirable while dealing with publicly-released software.
  • the customer support staff may have to perform several tasks to put the required diagnostic code into the application. First, it is necessary to get an exact copy of the source code from which the released product was built. Then, diagnostic logic must be manually inserted at appropriate places in the source code. The application then needs to be built in exactly the same manner in which the released product was built. If the added diagnostic code needs any further tuning, it may need to be changed by hand and the whole application rebuilt. This process can be very tedious and time consuming.
  • the source code may not be available at all. In this case, altering the source code to add diagnostic logic is simply not possible.
  • a system and method are presented for abstracting programming language complexity away from a user. Keywords are developed and utilized that are associated with functionality in the programming language. Keywords can be distinguished by appending a designated symbol, such as a “%” symbol.
  • a high-level language is based on these keywords, as well as semantics from the programming language. A user can then utilize this high-level language in writing code. The code written in the high-level language can then be interpreted for use with an application that is capable of accepting commands in the programming language.
  • the programming language can be any appropriate programming language, such as Java.
  • a user interface can be provided through which a user can utilize and program in this high-level language.
  • the high-level language can support at least programming language primitive types and user-specific types. This high-level language can be used to create a probe that can be injected into a compiled application, and can pass arguments to invoked methods or methods of the compiled applications.
  • FIG. 1 is diagram of a system in accordance with one embodiment of the present invention.
  • FIG. 2 is a flowchart showing steps of a method that can be used with the embodiment of FIG. 1.
  • Embodiments of tools that can be used in accordance with one embodiment of the present invention can provide a flexible and extensible mechanism for injecting instrumentation code into compiled Java applications.
  • a user can also implement necessary or “arbitrary” functionality at “arbitrary” injection points in the applications.
  • These embodiments can work directly on compiled Java classes and libraries, such that access to the original source code is not needed.
  • Tools in accordance with the present invention can utilize “probes”, or units of programmable instrumentation code that can be injected at requested locations.
  • the locations at which probes are to be injected are referred to as “injection points.”
  • a collection of probes can be implemented through a probe library.
  • a “directive file” can be used by an end user to direct the application instrumentation process.
  • a user can control the location(s) where the probes are injected.
  • the user can control the scope of probe injection to packages, classes, methods, and lines corresponding to original source by specifying directives in the directive file.
  • Tools in accordance with embodiments of the present invention can be used in scenarios such as debugging, application tracking, and performance monitoring.
  • One benefit of such a tool is that the tool can include a simple user interface, as the instrumentation procedure can be controlled with a simple configuration file.
  • Such a tool can also be lightweight, as only classes specified by the user are implemented.
  • a tool can also be extensible, as a user can create new probes as they are needed. Probe specifications can be written at a high level, such that the person creating a probe does not have to deal with low-level byte code details.
  • a tool can also allow the invoking of arbitrary Java runtime classes and methods in the probe body.
  • a tool in accordance with the one embodiment of the present invention acts as a tool to inject “arbitrary” code into an application, such as into compiled Java classes, under user direction.
  • instrumentation code By inserting instrumentation code after compilation, certain benefits can be obtained.
  • One benefit arises in the fact that program source code can be kept free of debugging code clutter.
  • the locations at which debugging code is inserted into the application can be controlled by the user. This allows the placement of instrumentation to be easily changed.
  • the instrumentation code to be inserted at specified instrumentation points can also be controlled by the user.
  • the code can be specified using a high level, special purpose language. This language can hide any low level details about the byte code from the user.
  • Such a tool can provide a generic and flexible way to inject arbitrary instrumentation probe code into compiled Java classes.
  • the tool allows the user to control the granularity at which instrumentation probes are to be inserted.
  • the scope can be limited to a group or groups of classes. Also, within the scope of eligible classes, a user can limit the methods into which probes are to be inserted.
  • a tool in accordance with one embodiment of the present invention can utilize a simple high level language, such as a Probe Description Language (PDL).
  • PDL Probe Description Language
  • Probe specifications can be created in PDL, such that a probe developer can be shielded from low level details about byte code.
  • PDL can, for instance, allow Java objects to created and used from the probe body with a syntax similar to Java.
  • PDL can be used to develop and implement a set of probe libraries. Since the probe body can create Java objects and invoke methods on these objects, as well as on other runtime classes, it is possible to create a wide variety of probes for specific needs. Once a probe library is developed, the library can be reused or used by others.
  • an end user will typically use already-existing probe libraries, as commonly needed probes can be supplied with the tool. Simply knowing how to use the tool should suffice for such users. If a custom probe needs to be created, the user person creating the probe may need to know PDL, or at least how to use a tool or interface that is capable of creating a probe using PDL.
  • a tool is driven by a global configuration file and a directive file.
  • the global configuration file can be used to store global parameter values. Global parameter values can be replaced or supplemented by variables in the directive file. The global configuration file may be seldom changed by the end user, if changed at all.
  • a directive file can be created by an end user for a specific instrumentation session. Together, these files can identify the available probe libraries and the classes to be instrumented. The files can also identify the probes that are to be applied to selected methods within eligible classes.
  • the insertion of selected probes into selected methods can be performed by an instrumentation engine 108 , as shown in FIG. 1.
  • the source code 100 is shown for illustration purposes and is not actually needed by the tool 106 .
  • the compiled classes 102 can be used as inputs to the tool 106 .
  • the dotted lines in the Figure are meant to demonstrate reference lines, while the solid arrows show information flow.
  • the compiled classes 102 and instrumentation directives 104 are used as inputs to the instrumentation engine 108 .
  • the instrumentation directive 104 refers to the probes created within the probe library.
  • the probe library 110 is written in PDL.
  • the instrumentation engine 108 can interpret PDL, so once the probes are specified in the instrumentation directive(s) the instrumentation engine 108 can take a specified probe, find out what the probe's instrumentation is in PDL, and inject it at the specified place(s).
  • the user interface to this tool is the instrumentation directive 104 .
  • An instrumentation directive can be implemented as a simple text file written in XML.
  • the file can tell the tool 106 which classes or sets of classes are to be implemented.
  • the file can specify the granularity at which the instrumentation is applied, such as for example at certain line numbers within a method.
  • the file can also specify several directives that inform the tool of which calls are to be applied, such as calls that apply pieces of code into an application as probes.
  • the directives can specify which probes are to be applied at which locations.
  • the tool can determine from the directive file which probes to apply and where to apply them.
  • the tool 106 itself contains the instrumentation engine 108 , a probe library descriptor 110 , and the PDL 112 .
  • the PDL block is a phantom component, as it is part of the tool and not actually a separate entity.
  • the instrumentation engine 108 is a general purpose injection engine that can interpret information given in an instrumentation directive 104 .
  • the probes can be contained in a probe description library 110 , which can be deployed as part of the tool 106 .
  • the libraries themselves can be created in PDL.
  • the code to be injected into the instrumented classes of the application can be extracted out of the instrumentation engine 108 itself.
  • the engine can provide generic mechanisms to define that which the user wants to inject.
  • the engine can allow the user to create probes with arbitrary implementations.
  • the instrumentation engine 108 can also inject probes into the instrumented classes 114 from a probe runtime library 116 .
  • the user can identify several components of an application to be used with the tool. For example, a user can know which classes make up an application. Since everything is contained in class files, a user can easily determine the class names. A user can know at least this amount of information about an application. A user can then, for example, instrument all these classes across the board.
  • a user can determine methods in those classes before or after the classes are instrumented. For example, if a user injects probes that will do program tracing, the user can learn about the methods of the program while the program is executing. The tool can, for example, print out all methods being instrumented in a class. A user can then selectively instrument the methods, and so on.
  • instrumenting a method a user can accomplish various tasks, such as instrumenting an application so that when it executes it will print method entries, exits, and arguments.
  • a user can create probes or use probes from a library that will accomplish those tasks.
  • probes When a probe is inserted, there will be some code that is injected, for example, at method entry and method exit.
  • a user can also make calls to other external run-time libraries, such as to get performance data.
  • a probe can identify time stamps and individual milestones in a method or application, can compute the differences between the timestamps, and can print out elapse times.
  • the tool allows users to make calls to external run-time libraries which can implement arbitrary functionality.
  • FIG. 2 A method is shown in FIG. 2 that can be used with the system of FIG. 1.
  • the user can specify the injection points in the application at which the code is to be injected 200 .
  • An instrumentation engine can compile the probe specifications in probe libraries into an internal representation 202 .
  • the instrumentation engine can then interpret the probe code into byte code 204 .
  • the instrumentation engine can then inject the appropriate byte code into method bodies at appropriate places 206 .
  • An instrumentation engine can provide a framework for injecting instrumentation probes into compiled Java classes.
  • An instrumentation engine can create instrumented class files from input class files, and can read and compile probe specifications from probe libraries.
  • An instrumentation engine can identify and read byte code for classes specified by user directives, and can identify injection points within classes specified by the user.
  • An injection engine can identify probes to be injected into specified classes and can inject probe instrumentation code into classes at appropriate injection points.
  • the injected code can be generated by compiling probes within the context of an injection point.
  • Global configuration information can be stored in a global configuration file, which can have the a format similar to that of the following examples.
  • an OPTIONS element can be empty or can include a number of OPTION elements.
  • Each OPTION element can specify a global parameter.
  • the “name” attribute of the OPTION element can identify the name of the parameter and the “value” attribute can identify its value.
  • a global parameter specified in the global configuration file can be over ridden by a corresponding OPTION element in a directive file. It can be further over ridden by a command line option.
  • TRACE TRACE
  • a TRACE parameter can be used to specify the tracing level to be used. Possible values include DEBUG, INFO, WARN, and ERROR. The WARN value can be set as the default.
  • OUTDIR OUTDIR, which can be used to specify the output root directory where instrumented classes can be created.
  • Another possible global parameter is itool.class.path. This parameter can specify the class path used to locate classes to be instrumented. If not specified, the parameter can default to a CLASSPATH environmental variable.
  • a itool.runtime.path variable can specify the class path used to locate runtime classes which will be used from the instrumentation code. If not specified, the variable can default to the CLASSPATH environmental variable. Parameter values for itool.class.path and itool.runtime.path can be specified in the same format that of a typical CLASSPATH environmental variable.
  • PROBE_LIBS Another element that can be included in a global configuration file is PROBE_LIBS.
  • a PROBE_LIBS element can be empty, or can include a number of PLIB elements.
  • a prefix attribute can be used to specify the name-space for the probe library. When using a prefix attribute, the names of all probes in the probe library can be prefixed with a specified prefix. The value attribute can specify the path to the probe library file.
  • the probe library file can contain specifications to a group of instrumentation probes. A list of available probe libraries can be supplemented with PLIB elements in the directive file.
  • An EXCLUDE_PATTERNS element in the global configuration file can be empty or can include a number of PATTERN elements. Each PATTERN element can specify a pattern used to exclude classes from the instrumentation process. A list of exclusion patterns can be supplemented with EXCLUDE_PATTERNS in the directive file.
  • a PATTERN element can specify the pattern to be used for matching strings. It can have many attributes, such as a TYPE attribute. When present, TYPE can have a value such as for example “re”, allowing the pattern specified by the “value” attribute to be taken as a Perl regular expression. Otherwise, it can allow for limited wild card specification.
  • SAFE_VALUES Another possible element in a global configuration file is SAFE_VALUES.
  • SAFE_VALUES There can be any number of PATTERN elements under a SAFE_VALUES element, or the element can be empty.
  • Each pattern can specify the class names whose “toString” method can be safely used within inserted instrumentation code.
  • the list of “safe” classes can be supplemented with SAFE_VALUES element in the directive file.
  • PDL can allow probe code to invoke methods on objects such as Java objects. If those methods are instrumented themselves, they can lead to undesirable consequences in certain circumstances, such as infinite recursion or infinite loops.
  • the SAFE_VALUES is a hint that it is OK to invoke methods on these classes and objects of these classes. This issue will be covered in more detail later in this document.
  • a directive file can be used to specify which probes are to be inserted into which class files.
  • a directive file can limit the scope of instrumentation to a group of classes. Additionally, a directive file can provide a section such as GLOBAL_OPTIONS to replace or supplement information specified by a global configuration file.
  • a directive file can define an itool.runtime.path to identify runtime classes.
  • the directive file can also define an itool.class.path to identify classes to be instrumented, and can define patterns to include or exclude classes from the instrumentation process.
  • a directive file can register probe libraries and specify directives to inject named probes into named classes. A sample directive file is shown below. Directive File Example #1 ⁇ ?xml version“1.0”encoding“UTF-8”?
  • An INSTRUMENT_SPEC element in the directive file can direct how the instrumentation should be performed.
  • Each INSTRUMENT_SPEC element can specify the classes to which instrumentation is to be applied.
  • the element INSTRUMENT_SPEC can contain one or more PROBE elements, which specify the probe(s) to be applied to eligible class(es).
  • the specified probes can be applied to classes listed in an INCLUDE_PATTERNS element, which are not in any EXCLUDE_PATTERNS in the global options or in EXCLUDE_PATTERNS of the current specification.
  • a directive file can have multiple INSTRUMENT_SPEC elements.
  • a PROBE element can specify the probe to be applied to eligible classes. It can have attributes such as NAME, which can be a required attribute to specify the name of the probe, which exists in one of the specified probe libraries.
  • pattern_type attribute exists, it can have a value such as “re”. If the value is “re”, patterns used in include_methods and exclude_methods are Perl regular expressions. This is similar to what is described with respect to the TYPE attribute in PATTERN elements. This attribute is optional in some embodiments.
  • a method_type attribute can be used to identify the type of methods within eligible classes to which a probe should be applied.
  • This attribute which can be optional, can include a list of values such as, for example:
  • constructor can be applied to class constructors
  • protected can be applied to protected methods
  • An include_methods attribute can specify comma-separated patterns, in order to identify methods to which the probe is to be applied. If this attribute is not included, all methods can be eligible. An exclude_methods attribute can also be included to identify methods which should be excluded. If this attribute is not included, no methods will be excluded.
  • a “lineno” attribute can be specified, for example, when the probe scope is %online.
  • the value of lineno can specify the line number in the original source where the probe is to be applied.
  • the value specified can be a number, such as 100, or a range, such as “100-110.”
  • a value of “*” can be used to imply that the probe is to be applied at all lines in the eligible method.
  • callsite When the probe scope is %oncall, a “callsite” attribute can be specified.
  • a probe can have zero or more arguments.
  • the name of the attribute should match with the name of the probe argument.
  • a probe can be applied to those methods which satisfy restrictions placed by attributes such as method_type, include_method and exclude_method. In one embodiment, if the method name matches patterns specified in exclude_methods, the probe is not applied. If the method name does not match patterns specified in include_methods, the probe is not applied. If the method type is not present in the method_type attribute, the probe is not applied.
  • More than one probe can be applied to the same method in a class, due to, for example, multiple PROBE elements within the same INSTRUMENT_SPEC element or due to multiple INSTRUMENT_SPEC elements within the directive file.
  • a high level description of the operation of a tool in accordance with one embodiment of the present invention is as follows.
  • a directive file is parsed to obtain certain information, such as a list of class archive libraries and directories containing compiled classes to be instrumented.
  • a list of classes specifically excluded from the instrumentation process is also parsed, as well as libraries of probes which are available for instrumentation.
  • a list of instrumentation specifications is obtained, comprising a subset of classes which should be considered for instrumentation within the scope of the instrumentation specification.
  • the list of specifications can also include classes to be specifically excluded from instrumentation within the scope of the instrumentation specification, and a list of probe directives, used to apply probes from available probe libraries which are to be injected in eligible classes.
  • the probe directives can further restrict the classes, methods within the classes, and locations within the methods where the probe can be applied.
  • probe library file can be parsed, and probes defined in the probe library can be identified. Parsed trees can be stored for defined probes in the probe repository.
  • the tool will determine if that class is explicitly excluded or is an interface, and will skip all such classes. For each executable method in the class, a list of eligible probe directives can be identified which are to be applied to this method in the class, obtained from the list of probe directives identified for all instrumentation specifications. For each eligible probe directive identified, a copy of the parsed representation of the specified probe can be obtained from the probe repository.
  • An “oninit” section of a probe body can specify the code to be emitted in the static class initializer after instrumentation. One purpose for doing so would be to capture some objects that might be used or re-used by different probes. If it exists, the “oninit” section can be complied to emit code in the static class initializer. An “oninit” section can create a reusable static object, which can be available once the class loads. The static initializer can execute when the class is being loaded. Thereafter, everything that is being created and initialized can be accessed from the bodies of the different probes.
  • An “onentry” section of a probe body can specify code to be emitted at method entry. If it exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive.
  • the “onentry” section can also be compiled to emit code at the method entry. The section can create objects and variables, and can initialize them.
  • An “onexit” section in the probe body can specify code to be emitted before a return from a method. If the section exists, the probe formal parameters can be replaced with actual parameters that are specified in the probe directive. All return instructions within the method can also be identified. For each return instruction within the method, the “onexit” section can be compiled within the context of the return instruction. A generated instruction sequence can be injected before the return instruction.
  • a “before_line” section in the probe body can specify code to be emitted before an instruction corresponding to a line in the original source code. If the section exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified that match the “lineno” attribute in the probe directive. For each injection point within the method, a “before_line” section can be compiled within the context of the injection point. The generated sequence can then be injected at applicable injection points.
  • a “before_call” section in the probe body can specify code to be emitted before a call to a named method. If the section exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified within the method where the named method is invoked. For each such injection point, a “before_call” section can be compiled within the context of the injection point. The generated sequence can then be injected at the injection point.
  • An “after_call” section in the probe body can specify code to be emitted after a call to a named method. If the section exists, the formal probe parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified within the method where the named method is invoked. For each such injection point, an“after_call” section can be compiled within the context of the injection point. A generated sequence can be injected at the injection point.
  • An “oncatch” section in the probe body can specify code to be emitted at the beginning of a catch block. If the section exists, formal probe parameters can again be replaced with actual parameters specified in the probe directive. All injection points involving catch blocks can be identified. For each injection point, the “oncatch” section can be compiled within the context of the injection point. A generated sequence can then be injected at the injection point.
  • any applied probe has an “oninit” section and the class does not have a static initializer method
  • a static initializer method can be created. Generated initialization code can be injected into the static initializer method. The modified class can then be saved to a designated location.
  • probes in PDL For example, a library of probes can be created by a user to perform specific tasks, such as application tracing and logging. A separate library can be created for performance measurements, such as might make use of suitable runtime libraries. Libraries of such probes can be created and shared among end users. Since PDL hides details about low level bytecode and class manipulation facilities, it can be very easy for a user to maintain and adapt created probes. A tool in accordance with one embodiment of the present invention can also be extended and integrated with other programs, such as integrated development environments, in order to enhance usability.
  • a custom language such as the Probe Description Language (PDL) can provide a high level notation to specify the body of an instrumentation probe. It can be implemented as a special purpose language that allows invoking methods on Java classes and objects. PDL can be used to write probe libraries, for example.
  • PDL Probe Description Language
  • PDL is a language that can be, in one implementation, very close to Java, although high-level languages abstracting away the complexity of other languages can be implemented in a similar fashion using the teachings included herein with respect to the Java language.
  • some of the semantics are the same as Java, such as the semantics used to call methods. This lessens the learning curve needed to understand and use PDL if a user knows basic Java commands.
  • PDL can link classes, objects, and methods in the Java world. For example, in the environment for such a tool a user may need to specify which pieces of code will end up where, such as when a user wants to inject something at method entry and something else just before method exit as part of the same probe.
  • PDL can also provide certain keywords, such as may be useful in computing certain information. For example, a user can use keywords to determine which class is currently running in an application. A user can also determine the current method being instrumented or the current line number. Certain features can be included that are tailored toward expressing the type of information that the user would like to evaluate as part of the probe.
  • PDL can provide a mechanism to describe instrumentation code.
  • PDL can support the use of Java primitive types, as well as user-specific types.
  • PDL can support simple arithmetic operations and string catenation.
  • PDL can allow the creation of static objects and variables, as well as objects and variables on stack.
  • PDL can allow calls to external Java runtime library methods and the creation of parameterized probes.
  • PDL can provide constructs to allow a probe writer to declare and instantiate variables of any Java type in the class static initializer. PDL can also allow a probe writer to declare and instantiate variables of any Java type on the stack. PDL can also allow for arithmetic operations. Literal values of Java primitive types can be defined and utilized, as well as literal String values. PDL can allow for string concatenations, and can provide access to classes, objects, and variables within an application being instrumented. This approach is consistent with Java scoping and access rules. PDL can be used to invoke methods on arbitrary Java runtime classes, and can allow a probe writer to pass arguments to invoked methods. Any accessible objects and variables can be passed as arguments, whether originating from the application or created in the probe. PDL can allow for conditional execution. PDL can also allow a probe writer to create parameterized probes, such that the same probe can be used in different contexts to operate on different arguments.
  • PDL can support comments or comment statements, such as C++ style comments. For example, anything following a double slash, or “//”, can be treated as a comment. Anything between a “/*” and a “*/”, possibly following a “*”, can also be treated as a comment.
  • keywords can start with a specific symbol, such as starting with a “%” character.
  • the keywords can also have specified meaning based on their context. Exceptions can include Java primitive types such as “int” and “long”. Following are keywords and possible meanings for one embodiment of the language.
  • the primary data types in this embodiment are byte, char, short, int, long, float, double, and boolean.
  • %file source file name corresponding to the class (java.lang.String)
  • %line current line number, or line number in the original source code where the code or probe will be injected (int)
  • %return a method return value, can be valid only with the “onexit” section
  • Using keywords such as %file, %class, %method, %line, and %retval in the probe body can yield corresponding values of type java.lang.String. These strings can participate in string concatenation to form other relevant strings. These keywords can also be combined with other variables and literal values and passed to appropriate runtime methods for further processing.
  • the syntax and semantics of PDL can also be extended by a sufficiently skilled probe writer.
  • PDL need not impose restrictions on which Java classes and methods can be invoked within the probe code. Therefore, it can be possible to invoke arbitrary runtime classes to implement arbitrary functionality.
  • probe sections can be compiled and generated code can be injected at designated injection points. Appropriate syntactic and semantic analysis can be performed within the context of each injection point to ensure that the probe body is valid within the context of each injection point. If such checks fail, an appropriate message can be printed and the probe kept from being injected.
  • Probes can be created to accept parameters. A specific instance of a probe directive using such a probe would pass the actual parameters as named attributes. Formal parameters can be replaced with acutal parameters while processing a probe directive at every probe injection point. This feature can allow the creation of generic probes which will inject appropriate code, based on the passed parameters.
  • probes can be written in a single file to create a probe library. Multiple probe libraries can be created and made available to the system for application instrumentation.
  • a user can inject specific probes at specific locations by creating a directive file.
  • a directive file can be implemented as a simple XML file. Elements within the directive file can identify the set of classes eligible for instrumentation, the set of classes to be executed for instrumentation, the set of probe libraries available, and the list of probes to be injected in eligible classes at eligible locations.
  • a PDL program can specify a probe library.
  • One example of the form of a PDL program, or probe library is given by: %pdl probe-library-name;//identifies the probe library name %probe probe-name ([probe-args...]) ⁇ %oninit ⁇ stmt-list ⁇ %onentry ⁇ stmt-list ⁇ %onexit ⁇ stmt-list ⁇ %before_line ⁇ stmt-list ⁇ %before_call ⁇ stmt-list ⁇ %after_call ⁇ stmt-list ⁇ %oncatch ⁇ stmt-list ⁇ ⁇
  • a probe can be uniquely identified by a library name and a probe name.
  • a probe arguments list such as may be referred to as “probe-args”, can be implemented as a comma-separated list of probe arguments.
  • the arguments can be used within the body of the probe symbolically.
  • the values of the probe arguments can be specified by the corresponding named attributes in a PROBE element of the directive file.
  • the probe body can have one or more sections.
  • a probe can contain any combination of sections, but sections such as “onexit”, “before_line”, “before_call”, “after_call”, and “oncatch,” described above, may need to be mutually exclusive. Each of these sections can be empty, or they can contain a number of statements. Each statement can end with a symbol such as a semi colon.
  • All Java types can be supported, including primitive types and user types.
  • An optional “initializer” can initialize a newly-created variable. Variables created in an %oninit section can be implicitly static. Variables created in an %onentry section can be created on the stack, and the scope of these variables can be entire method body. These variables can not be declared in other sections.
  • Variables declared within probes can be internally renamed using a name-altering scheme, such that the variables do not clash with variables in the application being instrumented. For example:
  • Another supported statement can be an expression.
  • PDL expressions can support simple arithmetic operations, such as the addition and subtraction of integer types.
  • Methods on Java classes, interfaces, and objects can be invoked with the same syntax as in Java. Passed parameter types can match corresponding method signatures. The tool can report an error if the parameters and signatures do not match. Values returned from such method calls can be assigned to variables of compatible types.
  • the objects on which the methods are invoked can be probe variables, as declared in the probe, or they can come from the application being instrumented.
  • t 0 java.lang.System.currentTimeMillis( );
  • variables can be declared only in %oninit and %onentry sections. Variables declared in an %oninit section can be implicitly static, and variables declared in an %onentry section can be created on a stack. It is also possible to not have any sections in a probe body. Such a probe can be treated as an empty probe. Access to variables from an application being instrumented can be required to satisfy normal Java scoping and access rules. Since the scope of a probe can be implicitly identified by analyzing the probe body, it may not be necessary to track the scope of a probe in the PDL syntax.
  • a user interface can be supplied which will help a user to generate a directive file. This can further lower the amount of knowledge required to inject probes into a compiled application.
  • a user interface can take the form of, for example, a point-and-click graphical user interface (GUI) or an identification tree. If using an identification tree, a user can click on nodes within the tree, with nodes representing, for example, classes and methods in the application. The user can simply select a point at which to insert a probe. Alternatively, a user can click through lists of methods and classes to select a position through a GUI, then select a probe from a list and specify parameters or options that might be needed by the probe.
  • GUI point-and-click graphical user interface
  • a user input to this tool can consist of a set of compiled class files along with a file containing instrumentation directives.
  • Input class files can be manipulated by the tool to produce functionally equivalent instrumented classes.
  • the instrumentation directives can be written using probes from available probe libraries.
  • the probe libraries can be created by generating probe library descriptor files in PDL. It is possible to create and deploy multiple probe libraries.
  • the instrumentation engine can read input class files and instrumentation directives provided by the user.
  • the instrumentation engine can refer to the probe library descriptors to identify the instrumentation specification for the probes. Using the instrumentation specifications, the instrumentation engine can emit appropriate byte-code within the class files to produce instrumented class files.
  • the instrumented classes can be executed with the provided runtime library to generate runtime traces.
  • the command line, global configuration, and directive file can be processed.
  • Probe libraries can then be compiled in order to build an internal representation for all available probes. A semantic analysis of each probe specification can be completed. Eligible classes are identified for instrumentation.
  • the class file can be read and a static initializer method created, if needed. For each method in the class, all probes can be identified which need to be applied to the method. For each probe to be applied, the probe application location is identified. Code in the static class initializer is emitted, if needed, based on the specification in the %oninit section. Code in the method body is emitted at the indicated location based on different sections in the probe body. The modified class file can then be written.
  • a user can make calls from the tool to a third-party library, such as a Log4j API, in order to accomplish tasks such as logging messages into the console.
  • a third-party library such as a Log4j API
  • Log4j provides a flexible way of sending messages to different destinations.
  • a user can insert calls within the source code and make calls to this API.
  • a probe library can be created around this API that can be used for application tracing.
  • the probe library can be a bridge between the application the user wants to instrument and the Log4j API.
  • the API can be called without having to alter the source code.
  • Embodiments in accordance with the present invention will allow development engineers to accomplish tasks such as identifying concurrency problems and race conditions. Development engineers can also use such tools to monitor the state of a program as it executes and analyze software logic. Embodiments in accordance with the present invention will also allow performance engineers and the like to make performance measurements at the micro level and do competitive analysis. Performance engineers can also do a statistical analysis over micro level measurements to expose bottlenecks and load imbalances.

Abstract

A high-level language can be used to abstract away programming language complexity from a user. The high-level language can be based upon and utilize some of the semantics of the programming language, but utilize keywords to call programming language functionality transparent to the user. This provides for a shorter learning curve for people who are somewhat familiar with the programming language, but might lack the knowledge or desire to personally code an entire application or method in the program language.
This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Description

    CLAIM OF PRIORITY
  • This application claims priority to U.S. Provisional Patent Application No. 60/349,457, filed Jan. 18, 2002, entitled “FLEXIBLE AND EXTENSIBLE JAVA BYTECODE,” as well as Application No. 60/349,586, filed Jan. 18, 2002, entitled “PROBE DESCRIPTION LANGUAGE,” each of which is hereby incorporated herein by reference.[0001]
  • COPYRIGHT NOTICE
  • A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. [0002]
  • CROSS-REFERENCED CASES
  • The following applications are cross-referenced and incorporated herein by reference: [0003]
  • U.S. patent application Ser. No. ______ entitled “FLEXIBLE AND EXTENSIBLE JAVA BYTECODE INSTRUMENTATION SYSTEM,” by Rajendra Inamdar, filed concurrently herewith. [0004]
  • FIELD OF THE INVENTION
  • The invention relates generally to inserting code into applications. [0005]
  • BACKGROUND
  • During the life cycle of a software application, there is often a need to observe how the application is behaving as it executes under typical running conditions. During the development phase, program behavior can be observed using a debugger. It is not always practical to use a debugger, however, as stopping a program at a break point can change the behavior of a program, especially in multi-threaded programs. Thus, placing traces in a program can sometimes be the only option. [0006]
  • Inserting debugging or tracing code in the source code of a program or application can have certain drawbacks. If debugging code is inserted in several places throughout an application, the source code can become cluttered with debug logic. Also, a programmer will have to anticipate the correct places to put the debug code when inserting it into the application. Once compiled, such debugging code cannot be changed. This can be undesirable while dealing with publicly-released software. [0007]
  • If a problem is reported against a specific release of a product, for example, the customer support staff may have to perform several tasks to put the required diagnostic code into the application. First, it is necessary to get an exact copy of the source code from which the released product was built. Then, diagnostic logic must be manually inserted at appropriate places in the source code. The application then needs to be built in exactly the same manner in which the released product was built. If the added diagnostic code needs any further tuning, it may need to be changed by hand and the whole application rebuilt. This process can be very tedious and time consuming. [0008]
  • If the problem is in a third party library or module, the source code may not be available at all. In this case, altering the source code to add diagnostic logic is simply not possible. [0009]
  • BRIEF SUMMARY
  • Although described with respect to compiled Java applications, it will be appreciated that similar advantages of application visibility, as well as other advantages, may obtain in other applications of the present invention. Such advantages may become apparent to one of ordinary skill in the art in light of the present disclosure or through practice of the invention. [0010]
  • It is an object of the present invention to aid in the development, testing, and analysis of software applications. [0011]
  • It is further an object of the present invention to create a tool that allows a user to analyze an application without having access to source code. [0012]
  • It is further an object of the present invention to create a tool that allows a user to analyze an application without placing any instrumentation code in the application. [0013]
  • It is further an object of the present invention to gain visibility into the working of applications, and allow that visibility to vary by user. [0014]
  • It is further an object of the present invention to be able to recreate problems in a typical execution environment, while in a testing or troubleshooting environment. It may be desirable to be able to observe micro level behavior without having to change the original source code. [0015]
  • It is further an object of the present invention to create a tool that allows a user to control a granularity of instrumentation. [0016]
  • It is further an object of the present invention to create a tool that provides a user with a rich set of instrumentation primitives, which can be applied at various levels. [0017]
  • It is further an object of the present invention to create a tool that allows a user to provide user-specific instrumentation code that satisfies certain constraints. [0018]
  • It is further an object of the present invention to create a tool that allows a user to analyze an application without altering program semantics. [0019]
  • It is further an object of the present invention to create a tool that allows a user to analyze an application while allowing the code instrumentation to retain symbolic information. [0020]
  • It is further an object of the present invention to create a tool that is light-weight in terms of usage as well as execution overheads. [0021]
  • A system and method are presented for abstracting programming language complexity away from a user. Keywords are developed and utilized that are associated with functionality in the programming language. Keywords can be distinguished by appending a designated symbol, such as a “%” symbol. A high-level language is based on these keywords, as well as semantics from the programming language. A user can then utilize this high-level language in writing code. The code written in the high-level language can then be interpreted for use with an application that is capable of accepting commands in the programming language. The programming language can be any appropriate programming language, such as Java. A user interface can be provided through which a user can utilize and program in this high-level language. The high-level language can support at least programming language primitive types and user-specific types. This high-level language can be used to create a probe that can be injected into a compiled application, and can pass arguments to invoked methods or methods of the compiled applications. [0022]
  • Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims. [0023]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is diagram of a system in accordance with one embodiment of the present invention. [0024]
  • FIG. 2 is a flowchart showing steps of a method that can be used with the embodiment of FIG. 1.[0025]
  • DETAILED DESCRIPTION
  • Embodiments of tools that can be used in accordance with one embodiment of the present invention can provide a flexible and extensible mechanism for injecting instrumentation code into compiled Java applications. A user can also implement necessary or “arbitrary” functionality at “arbitrary” injection points in the applications. These embodiments can work directly on compiled Java classes and libraries, such that access to the original source code is not needed. [0026]
  • Tools in accordance with the present invention can utilize “probes”, or units of programmable instrumentation code that can be injected at requested locations. The locations at which probes are to be injected are referred to as “injection points.” A collection of probes can be implemented through a probe library. A “directive file” can be used by an end user to direct the application instrumentation process. [0027]
  • With the help of a directive file, a user can control the location(s) where the probes are injected. The user can control the scope of probe injection to packages, classes, methods, and lines corresponding to original source by specifying directives in the directive file. [0028]
  • Tools in accordance with embodiments of the present invention can be used in scenarios such as debugging, application tracking, and performance monitoring. One benefit of such a tool is that the tool can include a simple user interface, as the instrumentation procedure can be controlled with a simple configuration file. Such a tool can also be lightweight, as only classes specified by the user are implemented. A tool can also be extensible, as a user can create new probes as they are needed. Probe specifications can be written at a high level, such that the person creating a probe does not have to deal with low-level byte code details. A tool can also allow the invoking of arbitrary Java runtime classes and methods in the probe body. [0029]
  • A tool in accordance with the one embodiment of the present invention acts as a tool to inject “arbitrary” code into an application, such as into compiled Java classes, under user direction. By inserting instrumentation code after compilation, certain benefits can be obtained. One benefit arises in the fact that program source code can be kept free of debugging code clutter. Also, the locations at which debugging code is inserted into the application can be controlled by the user. This allows the placement of instrumentation to be easily changed. The instrumentation code to be inserted at specified instrumentation points can also be controlled by the user. The code can be specified using a high level, special purpose language. This language can hide any low level details about the byte code from the user. [0030]
  • Such a tool can provide a generic and flexible way to inject arbitrary instrumentation probe code into compiled Java classes. The tool allows the user to control the granularity at which instrumentation probes are to be inserted. The scope can be limited to a group or groups of classes. Also, within the scope of eligible classes, a user can limit the methods into which probes are to be inserted. [0031]
  • Apart from controlling where probes are to be inserted, a user can specify that which defines a probe body. A tool in accordance with one embodiment of the present invention can utilize a simple high level language, such as a Probe Description Language (PDL). Probe specifications can be created in PDL, such that a probe developer can be shielded from low level details about byte code. PDL can, for instance, allow Java objects to created and used from the probe body with a syntax similar to Java. [0032]
  • PDL can be used to develop and implement a set of probe libraries. Since the probe body can create Java objects and invoke methods on these objects, as well as on other runtime classes, it is possible to create a wide variety of probes for specific needs. Once a probe library is developed, the library can be reused or used by others. [0033]
  • In one embodiment, an end user will typically use already-existing probe libraries, as commonly needed probes can be supplied with the tool. Simply knowing how to use the tool should suffice for such users. If a custom probe needs to be created, the user person creating the probe may need to know PDL, or at least how to use a tool or interface that is capable of creating a probe using PDL. [0034]
  • In one embodiment, a tool is driven by a global configuration file and a directive file. The global configuration file can be used to store global parameter values. Global parameter values can be replaced or supplemented by variables in the directive file. The global configuration file may be seldom changed by the end user, if changed at all. A directive file can be created by an end user for a specific instrumentation session. Together, these files can identify the available probe libraries and the classes to be instrumented. The files can also identify the probes that are to be applied to selected methods within eligible classes. [0035]
  • The insertion of selected probes into selected methods can be performed by an [0036] instrumentation engine 108, as shown in FIG. 1. In this figure, the source code 100 is shown for illustration purposes and is not actually needed by the tool 106. Once an application is compiled, the compiled classes 102 can be used as inputs to the tool 106.
  • The dotted lines in the Figure are meant to demonstrate reference lines, while the solid arrows show information flow. The compiled [0037] classes 102 and instrumentation directives 104 are used as inputs to the instrumentation engine 108. The instrumentation directive 104 refers to the probes created within the probe library. The probe library 110 is written in PDL. The instrumentation engine 108 can interpret PDL, so once the probes are specified in the instrumentation directive(s) the instrumentation engine 108 can take a specified probe, find out what the probe's instrumentation is in PDL, and inject it at the specified place(s).
  • The user interface to this tool is the [0038] instrumentation directive 104. An instrumentation directive can be implemented as a simple text file written in XML. The file can tell the tool 106 which classes or sets of classes are to be implemented. The file can specify the granularity at which the instrumentation is applied, such as for example at certain line numbers within a method. The file can also specify several directives that inform the tool of which calls are to be applied, such as calls that apply pieces of code into an application as probes. The directives can specify which probes are to be applied at which locations. The tool can determine from the directive file which probes to apply and where to apply them.
  • The [0039] tool 106 itself contains the instrumentation engine 108, a probe library descriptor 110, and the PDL 112. The PDL block is a phantom component, as it is part of the tool and not actually a separate entity. The instrumentation engine 108 is a general purpose injection engine that can interpret information given in an instrumentation directive 104. The probes can be contained in a probe description library 110, which can be deployed as part of the tool 106. The libraries themselves can be created in PDL.
  • The code to be injected into the instrumented classes of the application can be extracted out of the [0040] instrumentation engine 108 itself. The engine can provide generic mechanisms to define that which the user wants to inject. The engine can allow the user to create probes with arbitrary implementations. The instrumentation engine 108 can also inject probes into the instrumented classes 114 from a probe runtime library 116.
  • Even though a user does not have access to source code, the user can identify several components of an application to be used with the tool. For example, a user can know which classes make up an application. Since everything is contained in class files, a user can easily determine the class names. A user can know at least this amount of information about an application. A user can then, for example, instrument all these classes across the board. [0041]
  • Another possibility is that a user can determine methods in those classes before or after the classes are instrumented. For example, if a user injects probes that will do program tracing, the user can learn about the methods of the program while the program is executing. The tool can, for example, print out all methods being instrumented in a class. A user can then selectively instrument the methods, and so on. [0042]
  • When instrumenting a method a user can accomplish various tasks, such as instrumenting an application so that when it executes it will print method entries, exits, and arguments. A user can create probes or use probes from a library that will accomplish those tasks. When a probe is inserted, there will be some code that is injected, for example, at method entry and method exit. [0043]
  • A user can also make calls to other external run-time libraries, such as to get performance data. A probe can identify time stamps and individual milestones in a method or application, can compute the differences between the timestamps, and can print out elapse times. The tool allows users to make calls to external run-time libraries which can implement arbitrary functionality. [0044]
  • A method is shown in FIG. 2 that can be used with the system of FIG. 1. The user can specify the injection points in the application at which the code is to be injected [0045] 200. An instrumentation engine can compile the probe specifications in probe libraries into an internal representation 202. The instrumentation engine can then interpret the probe code into byte code 204. The instrumentation engine can then inject the appropriate byte code into method bodies at appropriate places 206. An instrumentation engine can provide a framework for injecting instrumentation probes into compiled Java classes. An instrumentation engine can create instrumented class files from input class files, and can read and compile probe specifications from probe libraries. An instrumentation engine can identify and read byte code for classes specified by user directives, and can identify injection points within classes specified by the user. An injection engine can identify probes to be injected into specified classes and can inject probe instrumentation code into classes at appropriate injection points. The injected code can be generated by compiling probes within the context of an injection point.
  • Global configuration information can be stored in a global configuration file, which can have the a format similar to that of the following examples. [0046]
    Global Configuration File Example #1
    <?xml version=“1.0” encoding=“UTF-8”?>
    <DOCROOT>
    <GLOBAL_OPTIONS>
    <OPTIONS>
    <OPTION name=“optname” value=“optvalue”/>...
    </OPTIONS>
    <PROBE_LIBS>
    <PLIB prefix=“prefix-name”value
    “probe-library-path”/>...
    </PROBE_LIBS>
    <EXCLUDE_PATTERNS>
    <PATTERN value=“class-name-pattern”/>...
    </EXCLUDE_PATTERNS>
    <SAFE_VALUES>
    <PATTERN value=“class-name-pattern”/>...
    </SAFE_VALUES>
    </GLOBAL_OPTIONS>
    </DOCROOT>
    Global Configuration File Example #2
    <?xml version“1.0” encoding“UTF-8”?>
    <DOCROOT>
     <GLOBAL_OPTIONS>
    <OPTIONS>
    <OPTION name=“TRACE” value=“DEBUG”/>
    <OPTION name=“OUTDIR” value=“output”/>
    <OPTION name=“itool.runtime.path” value
    =“c:/weblogic/lib/log4j.jar”/>
    </OPTIONS>
    <PROBE_LIBS>
    <PLIB prefix“log4j” value=“log4j.pdl”/>
    <PLIB prefix“jsr47” value=“jsr47.pdl”/>
    </PROBE_LIBS>
    <EXCLUDE_PATTERNS>
    <PATTERN value=“java.*”/>
    <PATTERN value=“javax.*38 />
    </EXCLUDE_PATTERNS>
    <SAFE_VALUES>
    <PATTERN value=“java.lang.*”/>
    <PATTERN value=“java.util.*”/>
    </SAFE_VALUES>
     </GLOBAL_OPTIONS>
    </DOCROOT>
  • In a global configuration file similar to that shown above, an OPTIONS element can be empty or can include a number of OPTION elements. Each OPTION element can specify a global parameter. The “name” attribute of the OPTION element can identify the name of the parameter and the “value” attribute can identify its value. A global parameter specified in the global configuration file can be over ridden by a corresponding OPTION element in a directive file. It can be further over ridden by a command line option. [0047]
  • Certain global parameters can be used by the tool. One such parameter is TRACE. A TRACE parameter can be used to specify the tracing level to be used. Possible values include DEBUG, INFO, WARN, and ERROR. The WARN value can be set as the default. Another such parameter is OUTDIR, which can be used to specify the output root directory where instrumented classes can be created. [0048]
  • Another possible global parameter is itool.class.path. This parameter can specify the class path used to locate classes to be instrumented. If not specified, the parameter can default to a CLASSPATH environmental variable. [0049]
  • A itool.runtime.path variable can specify the class path used to locate runtime classes which will be used from the instrumentation code. If not specified, the variable can default to the CLASSPATH environmental variable. Parameter values for itool.class.path and itool.runtime.path can be specified in the same format that of a typical CLASSPATH environmental variable. [0050]
  • Another element that can be included in a global configuration file is PROBE_LIBS. A PROBE_LIBS element can be empty, or can include a number of PLIB elements. A prefix attribute can be used to specify the name-space for the probe library. When using a prefix attribute, the names of all probes in the probe library can be prefixed with a specified prefix. The value attribute can specify the path to the probe library file. The probe library file can contain specifications to a group of instrumentation probes. A list of available probe libraries can be supplemented with PLIB elements in the directive file. [0051]
  • An EXCLUDE_PATTERNS element in the global configuration file can be empty or can include a number of PATTERN elements. Each PATTERN element can specify a pattern used to exclude classes from the instrumentation process. A list of exclusion patterns can be supplemented with EXCLUDE_PATTERNS in the directive file. [0052]
  • A PATTERN element can specify the pattern to be used for matching strings. It can have many attributes, such as a TYPE attribute. When present, TYPE can have a value such as for example “re”, allowing the pattern specified by the “value” attribute to be taken as a Perl regular expression. Otherwise, it can allow for limited wild card specification. The VALUE attribute can specify the pattern to be used for string matching. If TYPE's attribute value is not “re”, it can specify an exact match or start string if the pattern ends in “*”. For example: [0053]
    <!-- Matches all classes starting with “com.foo.”-->
    <PATTERN type=“re” value=”{circumflex over ( )}com. foo.\”/>
    <!-- specified as Perl regular expr. -->
    <PATTERN value=“com.foo.*”/>
    <!-- equivalent to above. -->
    <!-- Matches com.foo.MyClass only -->
    <PATTERN type=“re” value=“{circumflex over ( )}com\.foo\.Myclass$”/>
    <!-- specified as Perl regular expr. -->
    <PATTERN value“com.foo.Myclass”/>
    <!-- Matches com.foo.MyClass only -->
  • Another possible element in a global configuration file is SAFE_VALUES. There can be any number of PATTERN elements under a SAFE_VALUES element, or the element can be empty. Each pattern can specify the class names whose “toString” method can be safely used within inserted instrumentation code. The list of “safe” classes can be supplemented with SAFE_VALUES element in the directive file. [0054]
  • PDL can allow probe code to invoke methods on objects such as Java objects. If those methods are instrumented themselves, they can lead to undesirable consequences in certain circumstances, such as infinite recursion or infinite loops. The SAFE_VALUES is a hint that it is OK to invoke methods on these classes and objects of these classes. This issue will be covered in more detail later in this document. [0055]
  • Directive File [0056]
  • A directive file can be used to specify which probes are to be inserted into which class files. A directive file can limit the scope of instrumentation to a group of classes. Additionally, a directive file can provide a section such as GLOBAL_OPTIONS to replace or supplement information specified by a global configuration file. [0057]
  • A directive file can define an itool.runtime.path to identify runtime classes. The directive file can also define an itool.class.path to identify classes to be instrumented, and can define patterns to include or exclude classes from the instrumentation process. A directive file can register probe libraries and specify directives to inject named probes into named classes. A sample directive file is shown below. [0058]
    Directive File Example #1
    <?xml version“1.0”encoding“UTF-8”? >
    <DOCROOT>
    global options replace/supplement values
    specified by global configuration file
    <GLOBAL_OPTIONS>
    <OPTIONS>
    <OPTION name“optname”value“optvalue”/>
    </OPTIONS>
    <PROBE_LIBS>
    <PLIB prefix“prefix-name”value=“probe-library-
    path”/>
    </PROBE_LIBS>
    <EXCLUDE_PATTERNS>
    <PATTERN value=“class-name-pattern”/>
    </EXCLUDE_PATTERNS>
    <SAFE_VALUES>
    <PATTERN value“class-name-pattern”/>
    <SAFE VALUES>
    </GLOBAL_OPTIONS>
    <!--
    An instrument spec identifies the classes to which a set of probes
    need to be applied.
    <INSTRUMENT_SPEC>
    <INCLUDE_PATTERNS><!-- apply probes in this spec only to
    classes below -->
    <PATTERN value“class-name-pattern”/>...
    </INCLUDE_PATTERNS>
    <EXCLUDE_PATTERNS><!-- within this spec, exclude these
    classes
    from instrumentation -->
    <PATTERN value=“class-name-pattern”/>...
    </EXCLUDE_PATTERNS>
    <APPLY_PROBES><!-- apply following probes to eligible
    classes in this spec -->
    <PROBE name“probe-name”
    method_type=“method-type”
    pattern_type=“pattern-type”
    include_methods=“method-patterns”
    exclude_methods=“method-patterns”
    probe_arg=“probeargval”...
    /PROBE>...
    </APPY_PROBES>
     </INSTRUMENT_SPEC>
    </DOCROOT>
    Directive File Example #2
    <?xml versiow“1.0” encoding“UTF-8”?>
    <DOCROOT>
     <GLOBAL_OPTIONS>
    <OPTIONS>
    <OPTION name=“TRACE” value“debug”/>
    <OPTION name=“itool.class.path”
    value=“C:/weblogic/classes”/>
    </OPTIONS>
    <PROBE_LIBS>
    <PLIB prefix=“log4j” value“log4j.pdl”/>
    </PROBE_LIBS>
    <EXCLUDE_PATTERNS>
    <PATTERN value=“org.apache.*”/>
    </EXCLUDE_PATTERNS>
     </GLOBAL_OPTIONS>
     <INSTRUMENT_SPEC>
    <INCLUDE_PATTERNS>
    <PATTERN value=“com.beasys.engtools.Webcli.*”/>
    <PATTERN value=“com.beasys.engtools.util.*”/>
    </INCLUDE_PATTERNS>
    <EXCLUDE_PATTERNS>
    <PATTERN value
    “com.beasys.engtools.webcli.properties.*”/>
    </EXCLUDE_PATTERNS>
    <APPLY_PROBES>
    <PROBE name=“methodEntry” include_methods=“*”/>
    <!-- note how the String value of label is passed -->
    <PROBE name=“printExpr” lineno=“100-110”
    label=‘“Object-Name:”’expr=“objName”/>
    </APPY_PROBES>
     </INSTRUMENT_SPEC>
    </DOCROOT>
  • An INSTRUMENT_SPEC element in the directive file can direct how the instrumentation should be performed. Each INSTRUMENT_SPEC element can specify the classes to which instrumentation is to be applied. The element INSTRUMENT_SPEC can contain one or more PROBE elements, which specify the probe(s) to be applied to eligible class(es). The specified probes can be applied to classes listed in an INCLUDE_PATTERNS element, which are not in any EXCLUDE_PATTERNS in the global options or in EXCLUDE_PATTERNS of the current specification. A directive file can have multiple INSTRUMENT_SPEC elements. [0059]
  • A PROBE element can specify the probe to be applied to eligible classes. It can have attributes such as NAME, which can be a required attribute to specify the name of the probe, which exists in one of the specified probe libraries. [0060]
  • If a pattern_type attribute exists, it can have a value such as “re”. If the value is “re”, patterns used in include_methods and exclude_methods are Perl regular expressions. This is similar to what is described with respect to the TYPE attribute in PATTERN elements. This attribute is optional in some embodiments. [0061]
  • A method_type attribute can be used to identify the type of methods within eligible classes to which a probe should be applied. This attribute, which can be optional, can include a list of values such as, for example: [0062]
  • constructor: can be applied to class constructors [0063]
  • private: can be applied to private methods [0064]
  • protected: can be applied to protected methods [0065]
  • public: can be applied to public methods [0066]
  • all: can be applied to all methods [0067]
  • An include_methods attribute can specify comma-separated patterns, in order to identify methods to which the probe is to be applied. If this attribute is not included, all methods can be eligible. An exclude_methods attribute can also be included to identify methods which should be excluded. If this attribute is not included, no methods will be excluded. [0068]
  • A “lineno” attribute can be specified, for example, when the probe scope is %online. The value of lineno can specify the line number in the original source where the probe is to be applied. The value specified can be a number, such as 100, or a range, such as “100-110.” A value of “*” can be used to imply that the probe is to be applied at all lines in the eligible method. [0069]
  • When the probe scope is %oncall, a “callsite” attribute can be specified. The value of callsite can specify the pattern to identify call sites at which the probe will be applied. For example, setting callsite=“read” can apply the probe at the call to method “read” within the scope of the method being instrumented. [0070]
  • A probe can have zero or more arguments. When a probe has arguments, the arguments can be specified with a statement such as ProbeArg=“ProbeArgVal”. The name of the attribute should match with the name of the probe argument. [0071]
  • Within an eligible class, a probe can be applied to those methods which satisfy restrictions placed by attributes such as method_type, include_method and exclude_method. In one embodiment, if the method name matches patterns specified in exclude_methods, the probe is not applied. If the method name does not match patterns specified in include_methods, the probe is not applied. If the method type is not present in the method_type attribute, the probe is not applied. [0072]
  • More than one probe can be applied to the same method in a class, due to, for example, multiple PROBE elements within the same INSTRUMENT_SPEC element or due to multiple INSTRUMENT_SPEC elements within the directive file. [0073]
  • Principle of Operation [0074]
  • A high level description of the operation of a tool in accordance with one embodiment of the present invention is as follows. A directive file is parsed to obtain certain information, such as a list of class archive libraries and directories containing compiled classes to be instrumented. A list of classes specifically excluded from the instrumentation process is also parsed, as well as libraries of probes which are available for instrumentation. A list of instrumentation specifications is obtained, comprising a subset of classes which should be considered for instrumentation within the scope of the instrumentation specification. The list of specifications can also include classes to be specifically excluded from instrumentation within the scope of the instrumentation specification, and a list of probe directives, used to apply probes from available probe libraries which are to be injected in eligible classes. The probe directives can further restrict the classes, methods within the classes, and locations within the methods where the probe can be applied. There can be multiple instrumentation specifications, and each instrumentation specification can define different class subsets which are eligible for instrumentation within the scope of the instrumentation specification. [0075]
  • For each class archive library and directory containing compiled classes, valid class files can be identified as well as their fully qualified class names. For each probe library available for instrumentation, the probe library file can be parsed, and probes defined in the probe library can be identified. Parsed trees can be stored for defined probes in the probe repository. [0076]
  • For each identified class, the tool will determine if that class is explicitly excluded or is an interface, and will skip all such classes. For each executable method in the class, a list of eligible probe directives can be identified which are to be applied to this method in the class, obtained from the list of probe directives identified for all instrumentation specifications. For each eligible probe directive identified, a copy of the parsed representation of the specified probe can be obtained from the probe repository. [0077]
  • It can then be determined whether the formal probe parameters are specified in the probe directive. An “oninit” section of a probe body can specify the code to be emitted in the static class initializer after instrumentation. One purpose for doing so would be to capture some objects that might be used or re-used by different probes. If it exists, the “oninit” section can be complied to emit code in the static class initializer. An “oninit” section can create a reusable static object, which can be available once the class loads. The static initializer can execute when the class is being loaded. Thereafter, everything that is being created and initialized can be accessed from the bodies of the different probes. [0078]
  • An “onentry” section of a probe body can specify code to be emitted at method entry. If it exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive. The “onentry” section can also be compiled to emit code at the method entry. The section can create objects and variables, and can initialize them. [0079]
  • An “onexit” section in the probe body can specify code to be emitted before a return from a method. If the section exists, the probe formal parameters can be replaced with actual parameters that are specified in the probe directive. All return instructions within the method can also be identified. For each return instruction within the method, the “onexit” section can be compiled within the context of the return instruction. A generated instruction sequence can be injected before the return instruction. [0080]
  • A “before_line” section in the probe body can specify code to be emitted before an instruction corresponding to a line in the original source code. If the section exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified that match the “lineno” attribute in the probe directive. For each injection point within the method, a “before_line” section can be compiled within the context of the injection point. The generated sequence can then be injected at applicable injection points. [0081]
  • A “before_call” section in the probe body can specify code to be emitted before a call to a named method. If the section exists, the probe formal parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified within the method where the named method is invoked. For each such injection point, a “before_call” section can be compiled within the context of the injection point. The generated sequence can then be injected at the injection point. [0082]
  • An “after_call” section in the probe body can specify code to be emitted after a call to a named method. If the section exists, the formal probe parameters can be replaced with actual parameters specified in the probe directive. All injection points can be identified within the method where the named method is invoked. For each such injection point, an“after_call” section can be compiled within the context of the injection point. A generated sequence can be injected at the injection point. [0083]
  • An “oncatch” section in the probe body can specify code to be emitted at the beginning of a catch block. If the section exists, formal probe parameters can again be replaced with actual parameters specified in the probe directive. All injection points involving catch blocks can be identified. For each injection point, the “oncatch” section can be compiled within the context of the injection point. A generated sequence can then be injected at the injection point. [0084]
  • If any applied probe has an “oninit” section and the class does not have a static initializer method, a static initializer method can be created. Generated initialization code can be injected into the static initializer method. The modified class can then be saved to a designated location. [0085]
  • Certain users should be able to create probes in PDL for specific needs. For example, a library of probes can be created by a user to perform specific tasks, such as application tracing and logging. A separate library can be created for performance measurements, such as might make use of suitable runtime libraries. Libraries of such probes can be created and shared among end users. Since PDL hides details about low level bytecode and class manipulation facilities, it can be very easy for a user to maintain and adapt created probes. A tool in accordance with one embodiment of the present invention can also be extended and integrated with other programs, such as integrated development environments, in order to enhance usability. [0086]
  • Probe Description Language [0087]
  • A custom language such as the Probe Description Language (PDL) can provide a high level notation to specify the body of an instrumentation probe. It can be implemented as a special purpose language that allows invoking methods on Java classes and objects. PDL can be used to write probe libraries, for example. [0088]
  • PDL is a language that can be, in one implementation, very close to Java, although high-level languages abstracting away the complexity of other languages can be implemented in a similar fashion using the teachings included herein with respect to the Java language. In a Java-based embodiment, some of the semantics are the same as Java, such as the semantics used to call methods. This lessens the learning curve needed to understand and use PDL if a user knows basic Java commands. PDL can link classes, objects, and methods in the Java world. For example, in the environment for such a tool a user may need to specify which pieces of code will end up where, such as when a user wants to inject something at method entry and something else just before method exit as part of the same probe. [0089]
  • PDL can also provide certain keywords, such as may be useful in computing certain information. For example, a user can use keywords to determine which class is currently running in an application. A user can also determine the current method being instrumented or the current line number. Certain features can be included that are tailored toward expressing the type of information that the user would like to evaluate as part of the probe. [0090]
  • PDL can provide a mechanism to describe instrumentation code. PDL can support the use of Java primitive types, as well as user-specific types. PDL can support simple arithmetic operations and string catenation. PDL can allow the creation of static objects and variables, as well as objects and variables on stack. PDL can allow calls to external Java runtime library methods and the creation of parameterized probes. [0091]
  • PDL can provide constructs to allow a probe writer to declare and instantiate variables of any Java type in the class static initializer. PDL can also allow a probe writer to declare and instantiate variables of any Java type on the stack. PDL can also allow for arithmetic operations. Literal values of Java primitive types can be defined and utilized, as well as literal String values. PDL can allow for string concatenations, and can provide access to classes, objects, and variables within an application being instrumented. This approach is consistent with Java scoping and access rules. PDL can be used to invoke methods on arbitrary Java runtime classes, and can allow a probe writer to pass arguments to invoked methods. Any accessible objects and variables can be passed as arguments, whether originating from the application or created in the probe. PDL can allow for conditional execution. PDL can also allow a probe writer to create parameterized probes, such that the same probe can be used in different contexts to operate on different arguments. [0092]
  • PDL can support comments or comment statements, such as C++ style comments. For example, anything following a double slash, or “//”, can be treated as a comment. Anything between a “/*” and a “*/”, possibly following a “*”, can also be treated as a comment. [0093]
  • In order to specify that a word is a keyword in PDL, all keywords can start with a specific symbol, such as starting with a “%” character. The keywords can also have specified meaning based on their context. Exceptions can include Java primitive types such as “int” and “long”. Following are keywords and possible meanings for one embodiment of the language. The primary data types in this embodiment are byte, char, short, int, long, float, double, and boolean. [0094]
  • %pdl—probe description library [0095]
  • %probe—probe specification [0096]
  • %file—source file name corresponding to the class (java.lang.String) [0097]
  • %class—fully qualified class name being instrumented (java.lang.String) [0098]
  • %method—current method name being instrumented (java.lang.String) [0099]
  • %line—current line number, or line number in the original source code where the code or probe will be injected (int) [0100]
  • %retval—return value of the method [0101]
  • %argc—method parameter count [0102]
  • %argv—array of method parameters or arguments [0103]
  • %oninit—code to be emitted in static initializers [0104]
  • %onentry—code to be emitted at method entry [0105]
  • %onexit—code to be emitted at method exit [0106]
  • %before_line—code to be emitted before specified source line [0107]
  • %before_call—code to be emitted before call to specified method [0108]
  • %after_call—code to be emitted after call to specified method [0109]
  • %oncatch—code to be emitted in a catch block [0110]
  • %return—a method return value, can be valid only with the “onexit” section [0111]
  • %caught—a caught exception, can be valid only within the “oncatch” section [0112]
  • Using keywords such as %file, %class, %method, %line, and %retval in the probe body can yield corresponding values of type java.lang.String. These strings can participate in string concatenation to form other relevant strings. These keywords can also be combined with other variables and literal values and passed to appropriate runtime methods for further processing. The syntax and semantics of PDL can also be extended by a sufficiently skilled probe writer. [0113]
  • PDL need not impose restrictions on which Java classes and methods can be invoked within the probe code. Therefore, it can be possible to invoke arbitrary runtime classes to implement arbitrary functionality. [0114]
  • During an instrumentation process, probe sections can be compiled and generated code can be injected at designated injection points. Appropriate syntactic and semantic analysis can be performed within the context of each injection point to ensure that the probe body is valid within the context of each injection point. If such checks fail, an appropriate message can be printed and the probe kept from being injected. [0115]
  • Probes can be created to accept parameters. A specific instance of a probe directive using such a probe would pass the actual parameters as named attributes. Formal parameters can be replaced with acutal parameters while processing a probe directive at every probe injection point. This feature can allow the creation of generic probes which will inject appropriate code, based on the passed parameters. [0116]
  • The following example illustrates how a probe can be written to print the value of an expression at a given line. [0117]
    %probe printExprAtLine (label, expr)
    {
    %before_line
    {
    java.lang.System.out.println(
    (((“IVT printExprAtLine ”+
    %class +“::” + %method +
    “@Line +%line”+“”)+
    label) + expr)
    );
    }
    }
  • Multiple probes can be written in a single file to create a probe library. Multiple probe libraries can be created and made available to the system for application instrumentation. [0118]
  • A user can inject specific probes at specific locations by creating a directive file. A directive file can be implemented as a simple XML file. Elements within the directive file can identify the set of classes eligible for instrumentation, the set of classes to be executed for instrumentation, the set of probe libraries available, and the list of probes to be injected in eligible classes at eligible locations. [0119]
  • A PDL program can specify a probe library. One example of the form of a PDL program, or probe library, is given by: [0120]
    %pdl probe-library-name;//identifies the probe library name
    %probe probe-name ([probe-args...])
    {
    %oninit{ stmt-list }
    %onentry { stmt-list }
    %onexit { stmt-list }
    %before_line { stmt-list }
    %before_call { stmt-list }
    %after_call { stmt-list }
    %oncatch { stmt-list }
    }
  • A probe can be uniquely identified by a library name and a probe name. A probe arguments list, such as may be referred to as “probe-args”, can be implemented as a comma-separated list of probe arguments. The arguments can be used within the body of the probe symbolically. For a specific probe insertion, the values of the probe arguments can be specified by the corresponding named attributes in a PROBE element of the directive file. The probe body can have one or more sections. [0121]
  • A probe can contain any combination of sections, but sections such as “onexit”, “before_line”, “before_call”, “after_call”, and “oncatch,” described above, may need to be mutually exclusive. Each of these sections can be empty, or they can contain a number of statements. Each statement can end with a symbol such as a semi colon. [0122]
  • One type of statement that can be supported is a declaration. Variables can be declared using a declaration statement of the form: [0123]
  • type name[=initializer-expression]; [0124]
  • All Java types can be supported, including primitive types and user types. An optional “initializer” can initialize a newly-created variable. Variables created in an %oninit section can be implicitly static. Variables created in an %onentry section can be created on the stack, and the scope of these variables can be entire method body. These variables can not be declared in other sections. [0125]
  • Variables declared within probes can be internally renamed using a name-altering scheme, such that the variables do not clash with variables in the application being instrumented. For example: [0126]
  • int index; [0127]
  • java.util.Vector vector=new java.util.Vector( ); [0128]
  • long t[0129] 0=100;
  • Another statement that can be supported in PDL is an assignment. Assignment statements can be used to assign values to variables, and can take a form such as “name=expression;” given by the example “elapsed_time=(t[0130] 1−t0);” statement.
  • Another supported statement can be an expression. PDL expressions can support simple arithmetic operations, such as the addition and subtraction of integer types. Expressions can also support string catenation, method calls on Java classes and objects, and “new” operators to instantiate objects. An example is given by the statement “vector=new java.util.Vector( );”. [0131]
  • Methods on Java classes, interfaces, and objects can be invoked with the same syntax as in Java. Passed parameter types can match corresponding method signatures. The tool can report an error if the parameters and signatures do not match. Values returned from such method calls can be assigned to variables of compatible types. The objects on which the methods are invoked can be probe variables, as declared in the probe, or they can come from the application being instrumented. [0132]
  • EXAMPLE
  • t[0133] 0=java.lang.System.currentTimeMillis( );
  • java.lang.System.out.println(“Elapsed Time:”+(java.lang.System.currentTimeMillis( )−t[0134] 0));
  • In some embodiments, variables can be declared only in %oninit and %onentry sections. Variables declared in an %oninit section can be implicitly static, and variables declared in an %onentry section can be created on a stack. It is also possible to not have any sections in a probe body. Such a probe can be treated as an empty probe. Access to variables from an application being instrumented can be required to satisfy normal Java scoping and access rules. Since the scope of a probe can be implicitly identified by analyzing the probe body, it may not be necessary to track the scope of a probe in the PDL syntax. [0135]
  • Interface [0136]
  • Instead of creating a directive file by hand, or creating an XML file directly, a user interface can be supplied which will help a user to generate a directive file. This can further lower the amount of knowledge required to inject probes into a compiled application. [0137]
  • A user interface can take the form of, for example, a point-and-click graphical user interface (GUI) or an identification tree. If using an identification tree, a user can click on nodes within the tree, with nodes representing, for example, classes and methods in the application. The user can simply select a point at which to insert a probe. Alternatively, a user can click through lists of methods and classes to select a position through a GUI, then select a probe from a list and specify parameters or options that might be needed by the probe. [0138]
  • Architecture Overview [0139]
  • As discussed above, a user input to this tool can consist of a set of compiled class files along with a file containing instrumentation directives. Input class files can be manipulated by the tool to produce functionally equivalent instrumented classes. The instrumentation directives can be written using probes from available probe libraries. The probe libraries can be created by generating probe library descriptor files in PDL. It is possible to create and deploy multiple probe libraries. [0140]
  • The instrumentation engine can read input class files and instrumentation directives provided by the user. The instrumentation engine can refer to the probe library descriptors to identify the instrumentation specification for the probes. Using the instrumentation specifications, the instrumentation engine can emit appropriate byte-code within the class files to produce instrumented class files. [0141]
  • The instrumented classes can be executed with the provided runtime library to generate runtime traces. First, the command line, global configuration, and directive file can be processed. Probe libraries can then be compiled in order to build an internal representation for all available probes. A semantic analysis of each probe specification can be completed. Eligible classes are identified for instrumentation. [0142]
  • For each eligible class, the class file can be read and a static initializer method created, if needed. For each method in the class, all probes can be identified which need to be applied to the method. For each probe to be applied, the probe application location is identified. Code in the static class initializer is emitted, if needed, based on the specification in the %oninit section. Code in the method body is emitted at the indicated location based on different sections in the probe body. The modified class file can then be written. [0143]
  • Libraries [0144]
  • A user can make calls from the tool to a third-party library, such as a Log4j API, in order to accomplish tasks such as logging messages into the console. Using Log4j provides a flexible way of sending messages to different destinations. A user can insert calls within the source code and make calls to this API. A probe library can be created around this API that can be used for application tracing. The probe library can be a bridge between the application the user wants to instrument and the Log4j API. There can be a run-time library that does very specific things, such as application tracing and performance monitoring. The user can then leverage this run-time library by creating probes that make a bridge to that library. The API can be called without having to alter the source code. [0145]
  • Industrial Application [0146]
  • Embodiments in accordance with the present invention will allow development engineers to accomplish tasks such as identifying concurrency problems and race conditions. Development engineers can also use such tools to monitor the state of a program as it executes and analyze software logic. Embodiments in accordance with the present invention will also allow performance engineers and the like to make performance measurements at the micro level and do competitive analysis. Performance engineers can also do a statistical analysis over micro level measurements to expose bottlenecks and load imbalances. [0147]
  • The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence. [0148]

Claims (22)

What is claimed is:
1. A system for abstracting low level instruction complexity away from a user, comprising:
a high-level language based on the semantics of a programming language, said high-level language comprising keywords that represent functionality in the programming language; and
a mechanism for generating programming language code from said high-level language.
2. A system according to claim 1, wherein said high-level language further comprising a user interface allowing a user to program in said high-level language.
3. A system according to claim 1, wherein said high-level language allows invoking methods on Java classes and objects.
4. A system according to claim 1, wherein said high-level language allows linking of classes, objects, and methods.
5. A system according to claim 1, wherein said high-level language provides a mechanism to describe instrumentation code.
6. A system according to claim 1, wherein said high-level language supports native programming language types and user-specific types.
7. A system according to claim 1, wherein said high-level language allows a user to pass arguments to invoked methods without having any knowledge of the workings of those methods.
8. A system according to claim 1, wherein said high-level language provides for the creation of parameterized probes that can be used in different contexts to operate on different arguments.
9. A system according to claim 1, wherein said high-level language specifies that a word is a keyword by appending a symbol to the word.
10. A method for abstracting programming language complexity away from a user, comprising:
developing keywords that are associated with functionality in the programming language;
developing a high-level language based on the keywords and semantics from the programming language;
allowing a user to utilize the high-level language in writing code; and
interpreting the high-level language for use with an application capable of accepting commands in the programming language.
11. A method according to claim 10, wherein said programming language is Java.
12. A method according to claim 10, further comprising the step of specifying keywords by appending a designated symbol.
13. A method according to claim 10, further comprising the step of providing the user with a user interface through which the user can utilize the high-level language.
14. A method according to claim 10, further comprising the step of supporting programming language primitive types and user-specific types in the high-level language.
15. A method according to claim 10, further comprising the step of creating a probe using the high-level language that can be injected into a compiled application.
16. A method according to claim 10, further comprising the step of allowing the user to pass arguments to invoked methods using the high-level language.
17. A method according to claim 10, further comprising the step of altering any name in the high-level language that might conflict with a name in the programming language.
18. A computer-readable medium, comprising:
means for developing keywords that are associated with functionality in the programming language;
means for developing a high-level language based on the keywords and semantics from the programming language;
means for allowing a user to utilize the high-level language in writing code; and
means for interpreting the high-level language for use with an application capable of accepting commands in the programming language.
19. A computer program product for execution by a server computer for abstracting programming language complexity away from a user, comprising:
computer code for developing keywords that are associated with functionality in the programming language;
computer code for developing a high-level language based on the keywords and semantics from the programming language;
computer code for allowing a user to utilize the high-level language in writing code; and
computer code for interpreting the high-level language for use with an application capable of accepting commands in the programming language.
20. A system for abstracting programming language complexity away from a user, comprising:
means for developing keywords that are associated with functionality in the programming language;
means for developing a high-level language based on the keywords and semantics from the programming language;
means for allowing a user to utilize the high-level language in writing code; and
means for interpreting the high-level language for use with an application capable of accepting commands in the programming language.
21. A computer system comprising:
a processor;
object code executed by said processor, said object code configured to:
develop keywords that are associated with functionality in the programming language;
develop a high-level language based on the keywords and semantics from the programming language;
allow a user to utilize the high-level language in writing code; and
interpret the high-level language for use with an application capable of accepting commands in the programming language.
22. A computer data signal embodied in a transmission medium, comprising:
a code segment including instructions to develop keywords that are associated with functionality in the programming language;
a code segment including instructions to develop a high-level language based on the keywords and semantics from the programming language;
a code segment including instructions to allow a user to utilize the high-level language in writing code; and
a code segment including instructions to interpret the high-level language for use with an application capable of accepting commands in the programming language.
US10/287,185 2002-01-18 2002-11-04 Probe description language Abandoned US20030145309A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/287,185 US20030145309A1 (en) 2002-01-18 2002-11-04 Probe description language
PCT/US2003/001131 WO2003062986A1 (en) 2002-01-18 2003-01-15 Flexible and extensible java bytecode instrumentation system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US34958602P 2002-01-18 2002-01-18
US34945702P 2002-01-18 2002-01-18
US10/287,185 US20030145309A1 (en) 2002-01-18 2002-11-04 Probe description language

Publications (1)

Publication Number Publication Date
US20030145309A1 true US20030145309A1 (en) 2003-07-31

Family

ID=27617804

Family Applications (3)

Application Number Title Priority Date Filing Date
US10/287,213 Active 2024-07-16 US7281242B2 (en) 2002-01-18 2002-11-04 Flexible and extensible Java bytecode instrumentation system
US10/287,185 Abandoned US20030145309A1 (en) 2002-01-18 2002-11-04 Probe description language
US11/854,640 Active 2025-04-05 US7962905B2 (en) 2002-01-18 2007-09-13 Flexible and extensible java bytecode instrumentation system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/287,213 Active 2024-07-16 US7281242B2 (en) 2002-01-18 2002-11-04 Flexible and extensible Java bytecode instrumentation system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/854,640 Active 2025-04-05 US7962905B2 (en) 2002-01-18 2007-09-13 Flexible and extensible java bytecode instrumentation system

Country Status (2)

Country Link
US (3) US7281242B2 (en)
WO (1) WO2003062986A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040117771A1 (en) * 2002-12-12 2004-06-17 Microsoft Corporation Preprocessor-based source code instrumentation
US20040230956A1 (en) * 2002-11-07 2004-11-18 Cirne Lewis K. Simple method optimization
US20050091647A1 (en) * 2003-10-23 2005-04-28 Microsoft Corporation Use of attribution to describe management information
US20050114485A1 (en) * 2003-10-24 2005-05-26 Mccollum Raymond W. Using URI's to identify multiple instances with a common schema
US20060218533A1 (en) * 2005-03-24 2006-09-28 Koduru Rajendra K R Method and system for monitoring performance on a mobile device
US20060225051A1 (en) * 2005-04-05 2006-10-05 Cisco Technology, Inc. Method and system for code coverage
US20080005730A1 (en) * 2002-01-18 2008-01-03 Bea Systems, Inc. Flexible and extensible java bytecode instrumentation system
US7409677B1 (en) * 2004-11-16 2008-08-05 Sun Microsystems, Inc. Method and system for creation and use of embedded trace description
US20090228587A1 (en) * 2004-10-22 2009-09-10 International Business Machines Corporation Intelligent Performance Monitoring Based on User Transactions
US20110154226A1 (en) * 2009-12-21 2011-06-23 Sap Ag Chip model of an extensible plug-in architecture for enterprise mashups
US20120151464A1 (en) * 2010-12-14 2012-06-14 Bmc Software, Inc. Running Injected Code Prior to Execution of an Application
EP2565785A1 (en) * 2005-03-24 2013-03-06 Microsoft Corporation Method of instrumenting code having restrictive calling conventions
US20140325489A1 (en) * 2013-04-30 2014-10-30 Fujitsu Limited Programmable symbolic execution based dynamic checker
EP3179371A1 (en) * 2015-12-08 2017-06-14 Gilwa GmbH embedded systems Method and device for non-intrusively collecting function trace data
WO2021077735A1 (en) * 2019-10-24 2021-04-29 上海创景信息科技有限公司 Risc-v extension instruction-based source code coverage rate test method and system

Families Citing this family (104)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003073209A2 (en) * 2002-02-22 2003-09-04 Bea Systems, Inc. System and method for software application scoping
US7039644B2 (en) * 2002-09-17 2006-05-02 International Business Machines Corporation Problem determination method, system and program product
US7234080B2 (en) * 2002-10-18 2007-06-19 Computer Associates Think, Inc. Locating potential sources of memory leaks
US7415698B2 (en) * 2002-12-09 2008-08-19 International Business Machines Corporation Testing and debugging framework for application builders
US20040123279A1 (en) * 2002-12-18 2004-06-24 International Business Machines Corporation Method and system for auto-instrumenting java applications through probe injection
GB0229669D0 (en) * 2002-12-19 2003-01-29 Ibm A method for capturing computer application diagnostics
US7421682B2 (en) * 2003-11-10 2008-09-02 Microsoft Corporation Instrumentation injection for common language runtime
US7475386B1 (en) * 2003-11-14 2009-01-06 Sun Microsystems, Inc. Mechanism for disjoint instrumentation providers in a tracing framework
US7743367B1 (en) * 2003-12-30 2010-06-22 Sap Ag Registration method for supporting bytecode modification
US7739689B1 (en) * 2004-02-27 2010-06-15 Symantec Operating Corporation Internal monitoring of applications in a distributed management framework
US7788657B2 (en) * 2004-02-27 2010-08-31 Tvworks, Llc Targeted runtime compilation
US7424720B2 (en) * 2004-03-25 2008-09-09 International Business Machines Corporation Process and implementation for dynamically determining probe enablement using out of process correlating token
US7359831B2 (en) * 2004-05-21 2008-04-15 Bea Systems, Inc. Diagnostic context
US7395458B2 (en) * 2004-05-21 2008-07-01 Bea Systems, Inc. Diagnostic instrumentation
US8490064B2 (en) * 2004-05-21 2013-07-16 Oracle International Corporation Hierarchical debug
US8117593B1 (en) * 2004-06-10 2012-02-14 Siemens Industry, Inc. Method for highlighting selected tasks in a program code listing
US20050278703A1 (en) * 2004-06-15 2005-12-15 K5 Systems Inc. Method for using statistical analysis to monitor and analyze performance of new network infrastructure or software applications for deployment thereof
US7823137B2 (en) * 2004-10-21 2010-10-26 International Business Machines Corporation Process and implementation for using byte code insertion to modify a class definition to define and use probes for application components
GB0427670D0 (en) * 2004-12-16 2005-01-19 Ibm Methods, systems and computer program products for loading a resource
US20060200806A1 (en) * 2005-03-07 2006-09-07 Tasinga Khan M Apparatus, system, and method for trace insertion
US7661095B2 (en) * 2005-04-14 2010-02-09 Hewlett-Packard Development Company, L.P. System and method to build a callgraph for functions with multiple entry points
US7779399B2 (en) * 2005-05-16 2010-08-17 Armorize Technologies, Inc. System and method for securing web application code and verifying correctness of software
GB0510657D0 (en) * 2005-05-25 2005-06-29 Ibm Generating an application software library
US20060277525A1 (en) * 2005-06-06 2006-12-07 Microsoft Corporation Lexical, grammatical, and semantic inference mechanisms
US7568186B2 (en) * 2005-06-07 2009-07-28 International Business Machines Corporation Employing a mirror probe handler for seamless access to arguments of a probed function
US7945591B2 (en) * 2005-06-16 2011-05-17 International Business Machines Corporation Identifying problems, usage patterns, and performance in a database interface using aspect-oriented programming
CN100447743C (en) * 2005-06-24 2008-12-31 国际商业机器公司 System and method for localizing JAVA GUI application without modifying source code
US20070220370A1 (en) * 2006-01-12 2007-09-20 International Business Machines Corporation Mechanism to generate functional test cases for service oriented architecture (SOA) applications from errors encountered in development and runtime
US20070174490A1 (en) * 2006-01-25 2007-07-26 Greystripe Inc. System and methods for managing content in pre-existing mobile applications
US7818721B2 (en) * 2006-02-01 2010-10-19 Oracle America, Inc. Dynamic application tracing in virtual machine environments
US20080034352A1 (en) * 2006-06-29 2008-02-07 Mckinney Howard M System and method for determining unimportant probe locations by examination of byte code to identify method by name pattern
US7735060B2 (en) * 2006-06-29 2010-06-08 Augusta Systems, Inc. Method and system for rapidly developing and deploying sensor-enabled software applications
US8020146B2 (en) * 2006-07-24 2011-09-13 International Business Machines Corporation Applying deferred refactoring and API changes in an IDE
US20080127119A1 (en) * 2006-10-02 2008-05-29 Bulent Kasman Method and system for dynamic debugging of software
US20080127061A1 (en) * 2006-10-02 2008-05-29 Bulent Kasman Method and system for editing code
US20080127118A1 (en) * 2006-10-02 2008-05-29 Bulent Kasman Method and system for dynamic patching of software
US20080109794A1 (en) * 2006-11-07 2008-05-08 International Business Machines Corporation Method for Signaling Runtime Events to an Automated Test Script
US8490073B2 (en) * 2007-03-30 2013-07-16 International Business Machines Corporation Controlling tracing within compiled code
US9361129B2 (en) * 2007-08-01 2016-06-07 Microsoft Technology Licensing, Llc Instance interfaces and mix-ins for dynamic languages
US8578339B2 (en) * 2007-09-26 2013-11-05 Symantec Corporation Automatically adding bytecode to a software application to determine database access information
US8458670B2 (en) 2007-09-27 2013-06-04 Symantec Corporation Automatically adding bytecode to a software application to determine network communication information
US8887141B2 (en) * 2007-09-28 2014-11-11 Symantec Corporation Automatically modifying a native code module accessed from virtual machine bytecode to determine execution information
US20090119636A1 (en) * 2007-11-02 2009-05-07 Paul Kettley Instrumenting a compiled software routine for augmentation
US8584102B2 (en) * 2007-12-27 2013-11-12 Microsoft Corporation Creating and using deltas to modify existing computer code
US8359582B2 (en) * 2007-12-31 2013-01-22 Hewlett-Packard Development Company, L.P. Compiling and inserting code snippets at runtime
US8484623B2 (en) * 2008-03-26 2013-07-09 Avaya, Inc. Efficient program instrumentation
US8752007B2 (en) * 2008-03-26 2014-06-10 Avaya Inc. Automatic generation of run-time instrumenter
US8291399B2 (en) * 2008-03-26 2012-10-16 Avaya Inc. Off-line program analysis and run-time instrumentation
US8739145B2 (en) * 2008-03-26 2014-05-27 Avaya Inc. Super nested block method to minimize coverage testing overhead
US8141056B2 (en) * 2008-04-03 2012-03-20 International Business Machines Corporation Just-in-time dynamic instrumentation
US8166077B2 (en) * 2008-09-30 2012-04-24 International Business Machines Corporation Mapping a class, method, package, and/or pattern to a component
US8387023B2 (en) * 2008-10-16 2013-02-26 International Business Machines Corporation Instrumentation of computer-based application software
US10372581B1 (en) 2008-10-24 2019-08-06 Quest Software Inc. Instrumentation of program code for dynamic analysis
US8307345B2 (en) * 2008-11-04 2012-11-06 Ca, Inc. Intelligent engine for dynamic and rule based instrumentation of software
US9152456B2 (en) * 2009-01-23 2015-10-06 Oracle America, Inc. Efficient per-thread safepoints and local access
KR20110070468A (en) * 2009-12-18 2011-06-24 삼성전자주식회사 Apparatus for executing instrumentation and method thereof
US8566800B2 (en) 2010-05-11 2013-10-22 Ca, Inc. Detection of method calls to streamline diagnosis of custom code through dynamic instrumentation
US8473925B2 (en) 2010-05-11 2013-06-25 Ca, Inc. Conditional dynamic instrumentation of software in a specified transaction context
US8782612B2 (en) 2010-05-11 2014-07-15 Ca, Inc. Failsafe mechanism for dynamic instrumentation of software using callbacks
US8938729B2 (en) 2010-10-12 2015-01-20 Ca, Inc. Two pass automated application instrumentation
US8578487B2 (en) 2010-11-04 2013-11-05 Cylance Inc. System and method for internet security
US9116717B2 (en) 2011-05-27 2015-08-25 Cylance Inc. Run-time interception of software methods
US20130125096A1 (en) * 2011-08-31 2013-05-16 André Kruetzfeldt Systems and Methods for Dynamic Collection of Probe Call Sites
US8752015B2 (en) 2011-12-05 2014-06-10 Ca, Inc. Metadata merging in agent configuration files
US9411616B2 (en) 2011-12-09 2016-08-09 Ca, Inc. Classloader/instrumentation approach for invoking non-bound libraries
US10557061B2 (en) * 2011-12-26 2020-02-11 Dic Corporation Adhesive tape
US9367316B2 (en) 2012-03-16 2016-06-14 International Business Machines Corporation Run-time instrumentation indirect sampling by instruction operation code
US9430238B2 (en) * 2012-03-16 2016-08-30 International Business Machines Corporation Run-time-instrumentation controls emit instruction
US9405541B2 (en) 2012-03-16 2016-08-02 International Business Machines Corporation Run-time instrumentation indirect sampling by address
US9454462B2 (en) 2012-03-16 2016-09-27 International Business Machines Corporation Run-time instrumentation monitoring for processor characteristic changes
US9250902B2 (en) 2012-03-16 2016-02-02 International Business Machines Corporation Determining the status of run-time-instrumentation controls
KR101962248B1 (en) 2012-03-16 2019-03-27 삼성전자주식회사 Apparatus and method for supporting verification of reconfigurable processor
US9471315B2 (en) 2012-03-16 2016-10-18 International Business Machines Corporation Run-time instrumentation reporting
US9483268B2 (en) 2012-03-16 2016-11-01 International Business Machines Corporation Hardware based run-time instrumentation facility for managed run-times
US9158660B2 (en) 2012-03-16 2015-10-13 International Business Machines Corporation Controlling operation of a run-time instrumentation facility
US9465716B2 (en) 2012-03-16 2016-10-11 International Business Machines Corporation Run-time instrumentation directed sampling
US9411591B2 (en) 2012-03-16 2016-08-09 International Business Machines Corporation Run-time instrumentation sampling in transactional-execution mode
US9442824B2 (en) 2012-03-16 2016-09-13 International Business Machines Corporation Transformation of a program-event-recording event into a run-time instrumentation event
US9280447B2 (en) 2012-03-16 2016-03-08 International Business Machines Corporation Modifying run-time-instrumentation controls from a lesser-privileged state
KR101910934B1 (en) 2012-03-26 2018-12-28 삼성전자 주식회사 Apparatus and method for processing invalid operation of prologue or epilogue of loop
US9251026B2 (en) * 2012-03-31 2016-02-02 Bmc Software, Inc. Application instrumentation code extension
US9092568B2 (en) * 2012-04-30 2015-07-28 Nec Laboratories America, Inc. Method and system for correlated tracing with automated multi-layer function instrumentation localization
US9262301B2 (en) * 2012-05-10 2016-02-16 Telefonaktiebolaget L M Ericsson (Publ) Observability control with observability information file
US8656380B1 (en) * 2012-05-10 2014-02-18 Google Inc. Profiling an executable
US20150248343A1 (en) * 2012-07-27 2015-09-03 Freescale Semiconductor, Inc. Method and apparatus for implementing instrumentation code
US9798557B2 (en) * 2012-08-24 2017-10-24 Ca, Inc. Injection of updated classes for a java agent
US9817656B2 (en) 2012-08-24 2017-11-14 Ca, Inc. Hot rollback of updated agent
US8875096B1 (en) * 2012-09-25 2014-10-28 Amazon Technologies, Inc. Dynamic class loading
US9058493B1 (en) * 2013-01-16 2015-06-16 Amdocs Software Systems Limited System, method, and computer program for conditionally implementing protected content
US8954935B2 (en) 2013-03-14 2015-02-10 Pivotal Software, Inc. Method and system that filters byte-code instrumentation at the instrumentation level
US20150370547A1 (en) * 2013-04-08 2015-12-24 Mitsubishi Electric Corporation Program editing device, program editing method and program editing program
US10255158B2 (en) * 2013-10-15 2019-04-09 Oracle International Corporation Monitoring and diagnostics of business transaction failures
US9934128B2 (en) 2013-11-14 2018-04-03 Red Hat, Inc. Dynamic per-method probing during runtime
GB2530527A (en) * 2014-09-25 2016-03-30 Ibm A method for controlling a byte code transformer on detection of completion of an asynchronous command
US10223080B2 (en) * 2015-01-14 2019-03-05 Dynatrace Llc Method and system for automated, static instrumentation for applications designed for execution in environments with restricted resources
US10055332B2 (en) * 2016-02-12 2018-08-21 International Business Machines Corporation Variable detection in source code to reduce errors
CN107423037B (en) * 2016-03-09 2021-04-02 阿里巴巴集团控股有限公司 Application program interface positioning method and device
US11093374B2 (en) 2016-08-09 2021-08-17 SeaLights Technologies LTD System and method for continuous testing and delivery of software
KR101992419B1 (en) * 2017-07-31 2019-06-27 주식회사 티맥스 소프트 Apparatus and method for monitoring java application
CN108228214A (en) * 2017-12-29 2018-06-29 北京致远互联软件股份有限公司 A kind of update method of application program, medium and equipment
US11086759B2 (en) 2018-09-27 2021-08-10 SeaLights Technologies LTD System and method for probe injection for code coverage
US11250018B2 (en) * 2019-06-25 2022-02-15 Periscope Data Inc. Method for automated query language expansion and indexing
US11573885B1 (en) 2019-09-26 2023-02-07 SeaLights Technologies LTD System and method for test selection according to test impact analytics
US11379346B2 (en) * 2020-05-12 2022-07-05 Lightrun Platform LTD Systems and methods for debugging and application development

Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452457A (en) * 1993-01-29 1995-09-19 International Business Machines Corporation Program construct and methods/systems for optimizing assembled code for execution
US5758061A (en) * 1995-12-15 1998-05-26 Plum; Thomas S. Computer software testing method and apparatus
US5764989A (en) * 1996-02-29 1998-06-09 Supercede, Inc. Interactive software development system
US5901315A (en) * 1997-06-13 1999-05-04 International Business Machines Corporation Method for debugging a Java application having native method dynamic load libraries
US5946488A (en) * 1997-05-16 1999-08-31 Thnkage Ltd. Method for selectively and incrementally displaying the results of preprocessing
US6026237A (en) * 1997-11-03 2000-02-15 International Business Machines Corporation System and method for dynamic modification of class files
US6132109A (en) * 1994-04-12 2000-10-17 Synopsys, Inc. Architecture and methods for a hardware description language source level debugging system
US6279152B1 (en) * 1996-10-18 2001-08-21 Fujitsu Limited Apparatus and method for high-speed memory access
US20020133806A1 (en) * 2000-12-04 2002-09-19 Flanagan Cormac Andrias Method and apparatus for automatically inferring annotations
US6505342B1 (en) * 2000-05-31 2003-01-07 Siemens Corporate Research, Inc. System and method for functional testing of distributed, component-based software
US6539539B1 (en) * 1999-11-16 2003-03-25 Lucent Technologies Inc. Active probes for ensuring software package compatibility
US6658651B2 (en) * 1998-03-02 2003-12-02 Metrowerks Corporation Method and apparatus for analyzing software in a language-independent manner
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6687834B1 (en) * 2000-04-14 2004-02-03 International Business Machines Corporation Data processing system, method and program for generating a job within an automated test environment
US6721941B1 (en) * 1996-08-27 2004-04-13 Compuware Corporation Collection of timing and coverage data through a debugging interface
US20040078684A1 (en) * 2000-10-27 2004-04-22 Friedman George E. Enterprise test system having run time test object generation
US20040205550A1 (en) * 2001-06-29 2004-10-14 International Business Machines Corporation System and method for developing custom programmable tags
US6857119B1 (en) * 2001-09-25 2005-02-15 Oracle International Corporation Techniques for modifying a compiled application
US6918110B2 (en) * 2001-04-11 2005-07-12 Hewlett-Packard Development Company, L.P. Dynamic instrumentation of an executable program by means of causing a breakpoint at the entry point of a function and providing instrumentation code
US6968540B2 (en) * 2000-10-25 2005-11-22 Opnet Technologies Inc. Software instrumentation method and apparatus
US6993750B2 (en) * 2001-12-13 2006-01-31 Hewlett-Packard Development Company, L.P. Dynamic registration of dynamically generated code and corresponding unwind information

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7302675B2 (en) 2001-08-14 2007-11-27 National Instruments Corporation System and method for analyzing a graphical program using debugging graphical programs
US7281242B2 (en) 2002-01-18 2007-10-09 Bea Systems, Inc. Flexible and extensible Java bytecode instrumentation system
US6983455B2 (en) * 2002-04-10 2006-01-03 Sun Microsystems, Inc. Mechanism for profiling computer code

Patent Citations (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5530964A (en) * 1993-01-29 1996-06-25 International Business Machines Corporation Optimizing assembled code for execution using execution statistics collection, without inserting instructions in the code and reorganizing the code based on the statistics collected
US5452457A (en) * 1993-01-29 1995-09-19 International Business Machines Corporation Program construct and methods/systems for optimizing assembled code for execution
US6132109A (en) * 1994-04-12 2000-10-17 Synopsys, Inc. Architecture and methods for a hardware description language source level debugging system
US5758061A (en) * 1995-12-15 1998-05-26 Plum; Thomas S. Computer software testing method and apparatus
US5764989A (en) * 1996-02-29 1998-06-09 Supercede, Inc. Interactive software development system
US6721941B1 (en) * 1996-08-27 2004-04-13 Compuware Corporation Collection of timing and coverage data through a debugging interface
US6279152B1 (en) * 1996-10-18 2001-08-21 Fujitsu Limited Apparatus and method for high-speed memory access
US5946488A (en) * 1997-05-16 1999-08-31 Thnkage Ltd. Method for selectively and incrementally displaying the results of preprocessing
US5901315A (en) * 1997-06-13 1999-05-04 International Business Machines Corporation Method for debugging a Java application having native method dynamic load libraries
US6026237A (en) * 1997-11-03 2000-02-15 International Business Machines Corporation System and method for dynamic modification of class files
US6658651B2 (en) * 1998-03-02 2003-12-02 Metrowerks Corporation Method and apparatus for analyzing software in a language-independent manner
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6539539B1 (en) * 1999-11-16 2003-03-25 Lucent Technologies Inc. Active probes for ensuring software package compatibility
US6687834B1 (en) * 2000-04-14 2004-02-03 International Business Machines Corporation Data processing system, method and program for generating a job within an automated test environment
US6505342B1 (en) * 2000-05-31 2003-01-07 Siemens Corporate Research, Inc. System and method for functional testing of distributed, component-based software
US6968540B2 (en) * 2000-10-25 2005-11-22 Opnet Technologies Inc. Software instrumentation method and apparatus
US20040078684A1 (en) * 2000-10-27 2004-04-22 Friedman George E. Enterprise test system having run time test object generation
US20020133806A1 (en) * 2000-12-04 2002-09-19 Flanagan Cormac Andrias Method and apparatus for automatically inferring annotations
US6918110B2 (en) * 2001-04-11 2005-07-12 Hewlett-Packard Development Company, L.P. Dynamic instrumentation of an executable program by means of causing a breakpoint at the entry point of a function and providing instrumentation code
US20040205550A1 (en) * 2001-06-29 2004-10-14 International Business Machines Corporation System and method for developing custom programmable tags
US6857119B1 (en) * 2001-09-25 2005-02-15 Oracle International Corporation Techniques for modifying a compiled application
US6993750B2 (en) * 2001-12-13 2006-01-31 Hewlett-Packard Development Company, L.P. Dynamic registration of dynamically generated code and corresponding unwind information

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080005730A1 (en) * 2002-01-18 2008-01-03 Bea Systems, Inc. Flexible and extensible java bytecode instrumentation system
US7962905B2 (en) 2002-01-18 2011-06-14 Oracle International Corporation Flexible and extensible java bytecode instrumentation system
US9064041B1 (en) 2002-11-07 2015-06-23 Ca, Inc. Simple method optimization
US20040230956A1 (en) * 2002-11-07 2004-11-18 Cirne Lewis K. Simple method optimization
US8418145B2 (en) * 2002-11-07 2013-04-09 Ca, Inc. Simple method optimization
US20040117771A1 (en) * 2002-12-12 2004-06-17 Microsoft Corporation Preprocessor-based source code instrumentation
US7484205B2 (en) * 2002-12-12 2009-01-27 Microsoft Corporation Preprocessor-based source code instrumentation
US7765540B2 (en) 2003-10-23 2010-07-27 Microsoft Corporation Use of attribution to describe management information
US20050091647A1 (en) * 2003-10-23 2005-04-28 Microsoft Corporation Use of attribution to describe management information
US7712085B2 (en) 2003-10-23 2010-05-04 Microsoft Corporation Use of attribution to describe management information
US20050114485A1 (en) * 2003-10-24 2005-05-26 Mccollum Raymond W. Using URI's to identify multiple instances with a common schema
US7676560B2 (en) * 2003-10-24 2010-03-09 Microsoft Corporation Using URI's to identify multiple instances with a common schema
US20090228587A1 (en) * 2004-10-22 2009-09-10 International Business Machines Corporation Intelligent Performance Monitoring Based on User Transactions
US9111029B2 (en) * 2004-10-22 2015-08-18 International Business Machines Corporation Intelligent performance monitoring based on user transactions
US7409677B1 (en) * 2004-11-16 2008-08-05 Sun Microsystems, Inc. Method and system for creation and use of embedded trace description
US20060218533A1 (en) * 2005-03-24 2006-09-28 Koduru Rajendra K R Method and system for monitoring performance on a mobile device
US7788644B2 (en) * 2005-03-24 2010-08-31 Sap Ag Method and system for monitoring performance on a mobile device
EP2565785A1 (en) * 2005-03-24 2013-03-06 Microsoft Corporation Method of instrumenting code having restrictive calling conventions
US20060225051A1 (en) * 2005-04-05 2006-10-05 Cisco Technology, Inc. Method and system for code coverage
US20110154226A1 (en) * 2009-12-21 2011-06-23 Sap Ag Chip model of an extensible plug-in architecture for enterprise mashups
US8745598B2 (en) * 2010-12-14 2014-06-03 Bmc Software, Inc. Running injected code prior to execution of an application
US20120151464A1 (en) * 2010-12-14 2012-06-14 Bmc Software, Inc. Running Injected Code Prior to Execution of an Application
US20140325489A1 (en) * 2013-04-30 2014-10-30 Fujitsu Limited Programmable symbolic execution based dynamic checker
US9274925B2 (en) * 2013-04-30 2016-03-01 Fujitsu Limited Programmable symbolic execution based dynamic checker
EP3179371A1 (en) * 2015-12-08 2017-06-14 Gilwa GmbH embedded systems Method and device for non-intrusively collecting function trace data
WO2017097878A1 (en) * 2015-12-08 2017-06-15 Gliwa Gmbh Embedded Systems Method and device for non-intrusively collecting function trace data
US10831639B2 (en) 2015-12-08 2020-11-10 Gliwa Gmbh Embedded Systems Method and device for non-intrusively collecting function trace data
WO2021077735A1 (en) * 2019-10-24 2021-04-29 上海创景信息科技有限公司 Risc-v extension instruction-based source code coverage rate test method and system

Also Published As

Publication number Publication date
US7962905B2 (en) 2011-06-14
WO2003062986A1 (en) 2003-07-31
US20030149960A1 (en) 2003-08-07
US7281242B2 (en) 2007-10-09
US20080005730A1 (en) 2008-01-03

Similar Documents

Publication Publication Date Title
US7281242B2 (en) Flexible and extensible Java bytecode instrumentation system
Fähndrich et al. Embedded contract languages
US20110271258A1 (en) Software Development Tool
Chiş et al. The moldable debugger: A framework for developing domain-specific debuggers
US20110271250A1 (en) Software Development Tool
Chiş et al. Practical domain-specific debuggers using the Moldable Debugger framework
US20080022268A1 (en) Dependency Checking and Management of Source Code, Generated Source Code Files, and Library Files
Blagodarov et al. Tool demo: Raincode assembler compiler
Karaorman et al. jMonitor: Java runtime event specification and monitoring library
Garzella et al. Leveraging compiler intermediate representation for multi-and cross-language verification
Brendel et al. Generic library interception for improved performance measurement and insight
Szalay et al. The role of implicit conversions in erroneous function argument swapping in C++
Szalay et al. Flexible semi-automatic support for type migration of primitives for C/C++ programs
Rodrigues et al. Aspect-Oriented Webassembly Transformation
Császár et al. Building fast and reliable reverse engineering tools with Frida and Rust
Galindo Jiménez Automatic generation of test cases to improve code coverage in Java
Alankus et al. Advanced C++: Master the technique of confidently writing robust C++ code
Naudziuniene An infrastructure for tractable verification of JavaScript programs
Song et al. Enhancing source-level programming tools with an awareness of transparent program transformations
Ivanović Implementing constraint handling rules as a domain-specific language embedded in java
Wang et al. Improving the quality of aspectj application: Translating name-based pointcuts to analysis-based pointcuts
ShanmugaVelayutham Exectracer: Bytecode Instrumentation to Trace Java Code Execution
Kotrč Run-time performance testing in Java
Berger A test and verification environment for Java programs
Juarez-Martinez et al. A Join-point Model for Fine-grained Aspects

Legal Events

Date Code Title Description
AS Assignment

Owner name: BEA SYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INAMDAR, RAJENDRA;REEL/FRAME:013741/0302

Effective date: 20030120

AS Assignment

Owner name: BEA SYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INAMDAR, RAJENDRA;REEL/FRAME:013780/0764

Effective date: 20030120

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION