US20030145309A1 - Probe description language - Google Patents
Probe description language Download PDFInfo
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
- G06F11/364—Software 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
- 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.
- 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.
- The following applications are cross-referenced and incorporated herein by reference:
- U.S. patent application Ser. No. ______ entitled “FLEXIBLE AND EXTENSIBLE JAVA BYTECODE INSTRUMENTATION SYSTEM,” by Rajendra Inamdar, filed concurrently herewith.
- The invention relates generally to inserting code into applications.
- 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.
- 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.
- 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.
- 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.
- 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.
- It is an object of the present invention to aid in the development, testing, and analysis of software applications.
- 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.
- 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.
- 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.
- 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.
- It is further an object of the present invention to create a tool that allows a user to control a granularity of instrumentation.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.
- 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.
- 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.
- 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. 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- The insertion of selected probes into selected methods can be performed by an
instrumentation engine 108, as shown in FIG. 1. In this figure, thesource code 100 is shown for illustration purposes and is not actually needed by thetool 106. Once an application is compiled, the compiledclasses 102 can be used as inputs to thetool 106. - The dotted lines in the Figure are meant to demonstrate reference lines, while the solid arrows show information flow. The compiled
classes 102 andinstrumentation directives 104 are used as inputs to theinstrumentation engine 108. Theinstrumentation directive 104 refers to the probes created within the probe library. Theprobe library 110 is written in PDL. Theinstrumentation engine 108 can interpret PDL, so once the probes are specified in the instrumentation directive(s) theinstrumentation 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 thetool 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 theinstrumentation engine 108, aprobe library descriptor 110, and thePDL 112. The PDL block is a phantom component, as it is part of the tool and not actually a separate entity. Theinstrumentation engine 108 is a general purpose injection engine that can interpret information given in aninstrumentation directive 104. The probes can be contained in aprobe description library 110, which can be deployed as part of thetool 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. Theinstrumentation engine 108 can also inject probes into the instrumentedclasses 114 from aprobe 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.
- 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.
- 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.
- 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.
- 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 injected200. 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 intobyte code 204. The instrumentation engine can then inject the appropriate byte code into method bodies atappropriate 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.
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.
- 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.
- 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.
- 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. 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:
<!-- 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.
- 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.
- Directive File
- 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”? > <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.
- 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.
- 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.
- 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
- private: can be applied to private methods
- protected: can be applied to protected methods
- public: can be applied to public methods
- all: can be applied to all 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.
- 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.
- 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.
- 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.
- 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.
- Principle of Operation
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Probe Description Language
- 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 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.
- 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.
- 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.
- %pdl—probe description library
- %probe—probe specification
- %file—source file name corresponding to the class (java.lang.String)
- %class—fully qualified class name being instrumented (java.lang.String)
- %method—current method name being instrumented (java.lang.String)
- %line—current line number, or line number in the original source code where the code or probe will be injected (int)
- %retval—return value of the method
- %argc—method parameter count
- %argv—array of method parameters or arguments
- %oninit—code to be emitted in static initializers
- %onentry—code to be emitted at method entry
- %onexit—code to be emitted at method exit
- %before_line—code to be emitted before specified source line
- %before_call—code to be emitted before call to specified method
- %after_call—code to be emitted after call to specified method
- %oncatch—code to be emitted in a catch block
- %return—a method return value, can be valid only with the “onexit” section
- %caught—a caught exception, can be valid only within the “oncatch” 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.
- 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.
- 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.
- The following example illustrates how a probe can be written to print the value of an expression at a given line.
%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.
- 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. 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.
- 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.
- One type of statement that can be supported is a declaration. Variables can be declared using a declaration statement of the form:
- type name[=initializer-expression];
- 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:
- int index;
- java.util.Vector vector=new java.util.Vector( );
- long t0=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=(t1−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( );”.
- 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.
- t0=java.lang.System.currentTimeMillis( );
- java.lang.System.out.println(“Elapsed Time:”+(java.lang.System.currentTimeMillis( )−t0));
- 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.
- Interface
- 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.
- 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.
- Architecture Overview
- 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.
- 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. 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.
- 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.
- Libraries
- 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.
- Industrial Application
- 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.
- 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.
Claims (22)
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.
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)
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)
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)
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)
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 |
-
2002
- 2002-11-04 US US10/287,213 patent/US7281242B2/en active Active
- 2002-11-04 US US10/287,185 patent/US20030145309A1/en not_active Abandoned
-
2003
- 2003-01-15 WO PCT/US2003/001131 patent/WO2003062986A1/en not_active Application Discontinuation
-
2007
- 2007-09-13 US US11/854,640 patent/US7962905B2/en active Active
Patent Citations (22)
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)
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 |