Break on next called function or method in java debugger agent

Embodiments of the invention provide systems and methods for optimizing handling of breakpoints in a Java debugger agent. Embodiments provide a novel command that allows execution of the application in the debugger to stop or break at the beginning of a next called function or method (e.g., a “break on next called function” or “BNCF” command). When the BNCF command is given to the debugger, a flag may be set in the interpreter of the virtual machine to which the debugger is attached. On encountering a new method or function call, the flag is examined by the interpreter to determine whether it should stop or break in that call. If the flag is set, the interpreter will stop; otherwise the interpreter proceeds.

BACKGROUND

Embodiments of the present invention relate generally to debugging agents, and, more particularly, to breakpoint handling in Java™ debugging agents.

When debugging a software application, it is often desirable to set breakpoints to cause a debugger agent to stop at a predefined location for debugging purposes. A common feature of many software applications is that those applications branch into multiple possible method or function calls depending on certain circumstances. For example, an application may select from a number of functions to execute according to the value of a certain variable at a certain point in the execution of the application. When the application branches, it may be cumbersome or otherwise undesirable to set a breakpoint at each possible branch of the application.

BRIEF SUMMARY

Among other things, systems and methods are described for optimizing handling of breakpoints in a Java™ debugger agent. Embodiments provide a novel command in a Java™ debugger agent that allows execution of the application in the debugger to stop or break at the beginning of a next called function or method. In one embodiment, a “break on next called function” (or “BNCF”) command is issued by a user at a debugger front-end to a debugger agent at a debugger back-end prior to the debugger agent reaching a location where the application branches to one or more of multiple possible methods or functions. When the BNCF command is given to the debugger agent, a flag is set in the interpreter of the Java™ virtual machine to which the debugger is attached. On encountering a new method or function call, the flag is examined by the interpreter to determine whether it should stop or break in that call. If the flag is set, the interpreter will stop; otherwise the interpreter proceeds. For example, the call to a new method is detected by looking for one or more predefined opcodes (e.g., “invokevirtual,” “invokespecial,” “invokestatic,” and “invokeinterface”).

According to one set of embodiments, a method is provided for implementing breakpoints in a computer-implemented debugger environment having a front-end system and a back-end system. The method includes detecting a break on next called function (BNCF) command during execution of an application by a virtual machine running as part of the back-end system of the computer-implemented debugger environment; detecting an invoke command using the virtual machine during execution of the application and subsequent to detecting the BNCF command, the invoke command indicating invocation of a program method; and breaking execution of the application using the virtual machine upon invoking the method.

According to another set of embodiments, a method is provided for implementing breakpoints in a computer-implemented debugger environment having a front-end system and a back-end system. The method includes detecting an invoke command indicating invocation of a program method during execution of an application comprising the method using a virtual machine running as part of the back-end system of the computer-implemented debugger environment; determining whether a break on next called function (BNCF) flag was set during execution of the application by the virtual machine prior to detecting the invoke command; and when the BNCF flag was set during execution of the application by the virtual machine prior to detecting the invoke command, breaking execution of the application by the virtual machine upon invoking the program method.

According to yet another set of embodiments, a computer-implemented debugging system is provided. The computer-implemented debugging system includes a back-end subsystem configured to run a virtual machine. The virtual machine is configured to: execute an application comprising a number of program methods; detect an invoke command indicating invocation of one of the program methods during execution of the application; determine whether a break on next called function (BNCF) flag was set during execution of the application prior to detecting the invoke command; and break execution of the application upon invoking the one of the program methods when the BNCF flag was set during execution of the application by the virtual machine prior to detecting the invoke command.

DETAILED DESCRIPTION

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks.

Some embodiments are described herein for optimizing handling of breakpoints in a Java™ debugger agent. Embodiments provide a novel command in a Java™ debugger agent that allows execution of the application in the debugger to stop or break at the beginning of a next called function or method. A “break on next called function” (or “BNCF”) command is given to a debugger agent, for example, by a user at a debugger front-end via a user interface. When the BNCF command is given to the debugger, a flag is set in the interpreter of the Java™ virtual machine to which the debugger is attached. On encountering a new method or function call, the flag is examined by the interpreter to determine whether it should stop or break in that call. If the flag is set, the interpreter will stop; otherwise the interpreter proceeds. For example, the call to a new method is detected by looking for one or more predefined opcodes (e.g., “invokevirtual,” “invokespecial,” “invokestatic,” and “invokeinterface”).

Turning first toFIG. 1, a block diagram illustrating components of an exemplary operating environment is shown, in which various embodiments of the present invention may be implemented according to various embodiments. The system100can include one or more user computers105,110, which may be used to operate a client, whether a dedicated application, web browser, etc. The user computers105,110can be general purpose personal computers (including, merely by way of example, personal computers and/or laptop computers running various versions of Microsoft Corp.'s Windows and/or Apple Corp.'s Macintosh operating systems) and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation, the variety of GNU/Linux operating systems).

These user computers105,110may also have any of a variety of applications, including one or more development systems, database client and/or server applications, and web browser applications. Alternatively, the user computers105,110may be any other electronic device, such as a thin-client computer, Internet-enabled mobile telephone, and/or personal digital assistant, capable of communicating via a network (e.g., the network115described below) and/or displaying and navigating web pages or other types of electronic documents. Although the exemplary system100is shown with two user computers, any number of user computers may be supported.

The system may also include one or more server computers120,125,130which can be general purpose computers and/or specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.). One or more of the servers (e.g.,130) may be dedicated to running applications, such as a business application, a web server, an application server, etc. Such servers may be used to process requests from user computers105,110. The applications can also include any number of applications for controlling access to resources of the server computers120,125,130.

In some embodiments, an application server may create web pages dynamically for displaying on an end-user (client) system. The web pages created by the web application server may be forwarded to a user computer105via a web server. Similarly, the web server can receive web page requests and/or input data from a user computer and can forward the web page requests and/or input data to an application and/or a database server. Those skilled in the art will recognize that the functions described with respect to various types of servers may be performed by a single server and/or a plurality of specialized servers, depending on implementation-specific needs and parameters.

The system100may also include one or more databases135. The database(s)135may reside in a variety of locations. By way of example, a database135may reside on a storage medium local to (and/or resident in) one or more of the computers105,110,120,125,130. Alternatively, it may be remote from any or all of the computers105,110,120,125,130, and/or in communication (e.g., via the network115) with one or more of these. In a particular set of embodiments, the database135may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers105,110,120,125,130may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database135may be a relational database, such as Oracle 10 g, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 2illustrates an exemplary computer system200, in which various embodiments of the present invention may be implemented. The system200may be used to implement any of the computer systems described above. The computer system200is shown comprising hardware elements that may be electrically coupled via a bus255. The hardware elements may include one or more central processing units (CPUs)205, one or more input devices210(e.g., a mouse, a keyboard, etc.), and one or more output devices215(e.g., a display device, a printer, etc.). The computer system200may also include one or more storage device(s)220. By way of example, storage device(s)220may be disk drives, optical storage devices, a solid-state storage device such as a random access memory (RAM), and/or a read-only memory (ROM), which can be programmable, flash-updateable, and/or the like.

The computer system200may additionally include a computer-readable storage media reader225a, a communications system230(e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory240, which may include RAM and ROM devices as described above. In some embodiments, the computer system200may also include a processing acceleration unit235, which can include a DSP, a special-purpose processor, and/or the like.

The computer-readable storage media reader225acan further be connected to a computer-readable storage medium225b, together (and, optionally, in combination with storage device(s)220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system230may permit data to be exchanged with the network115and/or any other computer described above with respect to the system200.

The computer system200may also comprise software elements, shown as being currently located within a working memory240, including an operating system245and/or other code250, such as an application program (which may be a client application, web browser, mid-tier application, RDBMS, etc.). It should be appreciated that alternate embodiments of a computer system200may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. Software of computer system200may include code250for implementing embodiments of the present invention as described herein.

FIG. 3shows a block diagram of an illustrative debugging environment300, according to various embodiments. The debugging environment300includes a front-end system310and a back-end system350, in communication over a transport system340. As illustrated, the front-end system310may include a user interface320and a debugger front-end325. The back-end system350may include a virtual machine390, a debugger back-end360, and a number of data stores, including a bytecode source370and a breakpoint store380.

Embodiments of the debugging environment300are used for debugging a software application. The debugging environment300is described herein as a Java™ debugger for debugging Java™ bytecode. It will be appreciated that the novel functionality described herein may not be limited to Java™ environments; rather, other similar programming and/or debugging environments may be used without departing from the scope of the invention.

When debugging a software application (e.g., application, applet, function, etc.), it is often desirable to set breakpoints. The breakpoints may cause the debugger back-end360(e.g., debugger agent) to stop at a predefined location for debugging purposes. For example, it may be desirable for a programmer to see the value of variables at a particular point in a program where they would not normally be displayed to the user to determine whether a particular portion of the code (e.g., function) is operating as intended.

In many typical Java™ debuggers, a breakpoint may be requested (e.g., illustrated as breakpoint requests330) by a programmer. Upon receiving a breakpoint request330, the debugger back-end360assigns a request identifier and associates certain relevant information about the breakpoint request330in a data structure, illustrated as the breakpoint store380. For example, when the breakpoint request330is received, the debugger back-end360may store location information, including a class identifier, a method identifier, a method offset, etc., and associate the request identifier to the location information in the breakpoint store380.

The debugger back-end360may have access to the program code as the bytecode source370(e.g., the original or a copy of the original bytecode). When the debugger back-end360runs the bytecode source370for debugging, one or more copies of the program bytecode may be made, in which the source bytecode at each breakpoint request330location is replaced by a special breakpoint opcode. The debugger back-end360may then run the modified bytecode from the modified bytecode copy, rather than running the original bytecode, which may be stored in a location that is the same as or different from the location of the bytecode source370. The breakpoint opcode in the modified bytecode copy may be used by the debugger back-end360to detect the breakpoint and to inform the debugger front-end325(e.g., and thereby inform the breakpoint requester) that the breakpoint has been reached.

For example, a Java Virtual Machine (JVM) (e.g., virtual machine390) in the back-end system350may inform the debugger front-end325that a breakpoint associated with a particular breakpoint request330identifier has been reached. Typically, when the breakpoint opcode is reached by the debugger back-end360(e.g., using the virtual machine390), the debugger back-end360calls the function associated with the breakpoint opcode and supplies the function with the current program counter. The function (e.g., and/or other functions) and the program counter may be used to generate a thread identifier and/or other location information. The location information may then be used to search through the breakpoint store380data structure to find the associated request identifier.

Once the appropriate request identifier has been located, a reply packet335may be generated for passing desired information to the requestor (e.g., the programmer) at the debugger front-end325. The reply packet335may include the request identifier, the thread identifier, and the associated location information. For example, receipt of the reply packet335at the debugger front-end325may cause relevant information for the breakpoint request330(e.g., current values of local variables) to be displayed to the debugger front-end325(e.g., to a debugger user interface).

Notably, at certain portions of the program, bytecode may cause the program to branch according to one or more conditions. For example, at a particular location, a value of a variable or some other condition may cause the program to select between multiple execution paths. These multiple execution paths may be implemented as various methods (e.g., functions) which may be called according to the variable value or other condition.

According to one approach, a breakpoint request330is set at a location just prior to the branching. While this approach may allow only a single breakpoint request330to be set, it will be appreciated that the corresponding reply packet335may not reflect any information about the branching, as the branching has yet to occur. According to another approach, breakpoint requests330are set at the beginning of each possible method resulting from the branching, so as to ensure that any branching result will cause a break and will be reflected in a corresponding reply packet335. While this approach may yield more information about the branching result, it may also require a number of breakpoint requests330to be set at multiple locations. This may be cumbersome and may cause other undesirable results, as explained more fully below.

Embodiments provide additional functionality to the debugger back-end360(e.g., to the virtual machine390) by implementing a “break on next called function” (or “BNCF”) command that affects a BNCF flag375. The BNCF command allows execution of the application in the debugger to stop or break at the beginning of a next called function or method. The BNCF command may be issued at the debugger front-end325(e.g., by a user through the user interface320) and passed to the debugger back-end360. The BNCF command may typically be issued to the debugger back-end360prior to encountering a location where the application branches to one or more of multiple possible methods or functions.

When the BNCF command is given to the debugger back-end360, the BNCF flag375is set in the interpreter of the virtual machine390. For example, the BNCF flag375is “OFF” or “0” by default and is set to “ON” or “1” when the BNCF command is received at the debugger back-end360. On encountering a new (e.g., next) method or function call, the BNCF flag375is examined by the virtual machine390to determine whether it should stop or break in that call. If the BNCF flag375is set, the virtual machine390will stop; otherwise the virtual machine390proceeds.

In a typical Java™ environment (e.g., in the context of a Java™ virtual machine390), a call to a new method may be detected by looking for one or more of the following predefined opcodes: “invokevirtual,” “invokespecial,” “invokestatic,” and “invokeinterface.” Instance methods and/or static (or class) methods are invoked using these commands, regardless of whether the methods are native methods or Java™ methods. For example, class methods may be invoked by the virtual machine390according to a type of object reference known at the time of compiling, while instance methods may be invoked by the virtual machine390according to an actual object class, which may be known only at runtime. The “invokevirtual” command may typically be used to invoke instance methods, while the “invokestatic” command may be used to invoke static methods.

In some circumstances, instance methods are invoked using the “invokespecial” or “invokeinterface” commands. For example, the “invokespecial” command may be used when the method is invoked according to a reference type, instead of according to an object class, where static binding is preferable over dynamic binding (e.g., for instance initialization (“<init>”) methods, private methods, super keyword methods, etc.). The “invokeinterface” command may be used when the instance method is invoked according to a reference having an interface type.

It will be appreciated that certain features of particular debugger environments may yield different features and/or limitations. For example, in the context of a typical Java™ virtual machine390, programs are dynamically linked, such that method references are initially symbolic. As such, invoke commands refer to a constant pool entry initially containing a symbolic reference that identifies the method according at least to a class name, a method name, and a method descriptor. The virtual machine390resolves these symbolic references into direct references upon encountering an invoke instruction (e.g., the first time a method is invoked). The virtual machine390may also verify certain aspects of the program during resolution of the references, for example, to check for non-existent method references, improper syntax, improper authorization (e.g., to access private methods, etc.). When resolved and verified, the virtual machine390may invoke the method.

As described above, execution of an application (e.g., or a method of an application) may be stopped upon encountering a breakpoint opcode (corresponding to a breakpoint request330). Alternatively or additionally, the virtual machine390can be configured so that, whenever method invocation is encountered, the BNCF flag375is checked to determine whether it is set. If the BNCF flag375is set, a break may occur at the beginning of that next-invoked method (e.g., function, etc.). Some illustrative embodiments of application flows are illustrated inFIGS. 4A-4Dto further clarify certain aspects.

FIG. 4Ashows an application flow400ausing an illustrative prior art approach for debugging a branching portion of a program using breakpoints. A local variable “x”410is passed to a branching code420portion of the program bytecode. For example, the branching code420invokes one of three methods according to the value of local variable “x”410, as represented by the following pseudo-code:

According to this pseudo-code, local variable “x”410is evaluated, and one of three functions (“f1,” “f2,” or “f3”) is called according to the value of local variable “x”410. In particular, if local variable “x”410equals zero, a first function, “f1”440a, is invoked. If local variable “x”410equals one, a second function, “f2”440b, is invoked. If local variable “x”410has any other value (e.g., if local variable “x”410equals two), a third function, “f3”440c, is invoked.

Suppose it is desirable to analyze certain conditions (e.g., the values of certain variables) at the start of whichever function440is called by the branching code420. As illustrated, a prior art approach may include putting a breakpoint430at the start of each function440. For example, a first breakpoint430aopcode is placed at the beginning of the bytecode for “f1”440a. If local variable “x”410equals one, the branching code420may invoke “f1”440a, thereby breaking according to breakpoint430a. Notably, three breakpoints430may be needed to account for all the possible invocations of the branching code420.

FIG. 4Bshows an application flow400bfor debugging a branching portion of a program using BNCF functionality, according to various embodiments. As inFIG. 4A, a local variable “x”410is passed to a branching code420portion of the program bytecode, which invokes one of three methods according to the value of local variable “x”410. Instead of placing a breakpoint at the beginning of each potentially invoked function440(e.g., as indicated by breakpoints430inFIG. 4A), a BNCF command450is issued (e.g., prior to encountering the branching code420) to the virtual machine390. For example, the BNCF command450is given to the virtual machine390prior to the virtual machine390implementing any branching according to the branching code420, thereby setting the BNCF flag375.

When the virtual machine390encounters the BNCF flag375, it determines whether the BNCF flag375is set; if so, the virtual machine390breaks execution at the beginning of any next-called method (e.g., upon detection of any of the invoke commands described above). It is worth noting that only a single BNCF command450is needed, rather than inserting multiple breakpoints430(e.g., as inFIG. 4A). It is further worth noting that any branching may be covered by the single BNCF command450, such that no invocations of methods will be missed by failing to place breakpoints330at those methods.

The application flows400ofFIGS. 4A and 4Bshow a very simple case of a single branching event based on a single variable using simple function invocation, etc. The BNCF command450may yield further functionality with more complex application flows400. For example,FIG. 4Cshows another application flow400cusing an illustrative prior art approach for debugging a branching portion of a program using breakpoints.

As inFIG. 4A, a local variable “x”410is passed to a branching code420portion of the program bytecode, which invokes one of three methods according to the value of local variable “x”410. Also as inFIG. 4A, breakpoints430have been set at the beginning of each function440that may be invoked by the branching code420. Unlike inFIG. 4A, the application flow400cofFIG. 4Cincludes a further invocation of method “f2”440bat the end of method “f1”440a. Because the breakpoint430bis set at the beginning of “f2”440b, this breakpoint may be encountered by the virtual machine390when “f2”440bis invoked by the branching code420or by “f1”440a. This may be undesirable, as this result may cause execution of the program to break at an undesirable location (e.g., immediately following execution of “f1”440a, instead of immediately following execution of the branching code420), or the result may make it more difficult for a user to distinguish the cause of execution of “f2”440b(e.g., whether “f2”440bwas executed by “f1”440aor by the branching code420).

FIG. 4Dshows an application flow400dfor debugging a branching portion of a program using BNCF functionality, according to various embodiments. As inFIG. 4C, a local variable “x”410is passed to a branching code420portion of the program bytecode, which invokes one of three methods according to the value of local variable “x”410. Instead of placing a breakpoint at the beginning of each potentially invoked function440(e.g., as indicated by breakpoints430inFIG. 4C), a single BNCF command450is issued prior to encountering the branching code420. A BNCF flag375is set according to the BNCF command450.

As inFIG. 4B, when the virtual machine390encounters the BNCF command450, it analyzes the BNCF flag375and determines that the BNCF flag375is set. Accordingly, the virtual machine390breaks execution at the beginning of any next-called method (e.g., upon detection of any of the invoke commands described above). Notably, unlike inFIG. 4C, execution of the program may break only where desired, only following execution of the branching code420(i.e., there is no breakpoint at the beginning of “f2”440b, so no breakpoint will be encountered immediately following execution of “f1”440a). Further, unlike inFIG. 4C, use of the BNCF command450(e.g., with or without use of additional breakpoints) may allow a user to distinguish the cause of execution of “f2”440b. For example, a reply packet335corresponding to the BNCF command450may only be returned to the debugger front-end325when “f2”440bis invoked by the branching code420, and not when invoked by “f1”440a.

Turning toFIG. 5, a flow diagram is shown of an illustrative method500for providing a BNCF command to a debugger environment, according to various embodiments. In some embodiments, the method500is executed in a system like the debugger environment300ofFIG. 3. Embodiments of the method500begin at block504by issuing a BNCF command from the debugger front-end (e.g., while the debugger agent is executing at a location in the application). For example, a user issues a BNCF command450prior to a particular set of branching code in the application via the user interface320of a debugger front-end325.

At block508, the BNCF command is passed to the debugger back-end. For example, the BNCF command450is communicated via the transport system340from the debugger front-end325to the debugger back-end360. At block512, according to the BNCF command, the debugger back-end may set a BNCF flag for use by the debugger agent. For example, the debugger back-end360sets the BNCF flag375to “ON” for use by the virtual machine290.

Having given the BNCF command450to the debugger back-end360, the BNCF command450may effectively be used by the virtual machine390as requested, for example, according to the BNCF flag375.FIG. 6shows a flow diagram of an illustrative method600for interpreting a BNCF command in a debugger environment, according to various embodiments. In some embodiments, the method600is executed in a system like the debugger environment300ofFIG. 3.

Embodiments of the method600begin at block604by detecting a next function or method call. For example, a Java™ debugger agent may detect one of the four invoke commands discussed above. Embodiments of the interpreter are configured so that, having detected the next method or function call, the virtual machine390may examine any flags at block608. At block612, a determination is made as to whether any BNCF flags have been set, for example, according to the method500ofFIG. 5.

If it is determined at block612that a BNCF flag has been set, the virtual machine390may stop execution of the program at block616. In some embodiments, at block620, a corresponding reply packet335is generated and communicated to the debugger front-end325(e.g., via the transport system340). Further, in some embodiments, the BNCF flag is reset to its default (“unset”) value at block624. If it is determined at block612that a BNCF flag has not been set, the virtual machine390may proceed with normal execution of the program at block628.