Techniques for debugging computer programs involving multiple programming languages Number:7,107,578 from the United States Patent and Trademark Office (PTO) owispatent

Title: Techniques for debugging computer programs involving multiple programming languages

Abstract: Techniques for debugging a computer program that includes multiple modules written in multiple languages allow machines for the multiple languages to interface with a single debugger client using a standard interface. The techniques include storing a mapping that maps language constructs of a first language into language constructs of a second language. While a first machine is executing a first module that is written in the first language, the mapping is used to generate debugging information based on language constructs of the second language. The debugging information is sent to a debugger process designed for debugging programs written in the second language.

Patent Number: 7,107,578 Issued on 09/12/2006 to Alpern

---

Inventors:	Alpern; David M. (San Jose, CA)
Assignee:	Oracle International Corporation (Redwood Shores, CA)
Appl. No.:	10/144,144
Filed:	May 10, 2002

---

Current U.S. Class:	717/124 ; 717/127; 717/128; 717/129; 717/137
Current International Class:	G06F 9/44 (20060101)
Field of Search:	717/124-130 719/318,330

---

References Cited [Referenced By]

---

U.S. Patent Documents

	5247676		September 1993		Ozur et al.
	5371746		December 1994		Yamashita et al.
	5430876		July 1995		Schreiber et al.
	5457797		October 1995		Butterworth et al.
	5787245		July 1998		You et al.
	5794047		August 1998		Meier
	5802371		September 1998		Meier
	5818445		October 1998		Sanderson et al.
	5901315		May 1999		Edwards et al.
	6026362		February 2000		Kim et al.
	6126328		October 2000		Mallory et al.
	6314429		November 2001		Simser
	6353923		March 2002		Bogle et al.
	6826746		November 2004		Evans et al.

Other References

Johnson "Debugging Clossary" 1981, Hewlett-Packard. cited by examiner . "MicrosoftC/C++ Version 7.0, Environment and Tools For MS-DOS and Windows Operating Systems", Microsoft Corporation, 1991, pp. 393-398. cited by other . Klaus-Peter Lohr et al., "DAPHNE-Support for Distributed Applications Programming in Heterogeneous Computer Networks", IEEE, pp. 63-71, 1988. cited by other . Antonio Corradi et al., "Error Recovery Mechanisms for Remote Procedure Call-Based Systems", IEEE, 1989, pp. 502-507. cited by other . Charles A. Meyer et al., "Design and Test Strategies for a Safety-Critical Embedded Executive", ACM, Dec. 1996, pp. 29-37. cited by other . Helge Behrends, "Simulation-based Debugging of Active Databases", IEEE, Feb. 1994, pp. 172-180. cited by other.

Primary Examiner: Chaki; Kakali
Assistant Examiner: Mitchell; Jason
Attorney, Agent or Firm: Hickman Palermo Truong & Becker LLP

---

Parent Case Text

---

CROSS REFERENCE TO RELATED APPLICATION

This application claims benefit of Provisional Application 60/324,722, filed Sep. 24, 2001, the entire contents of which is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. .sctn. 119(e).

---

Claims

---

What is claimed is:

1. A method for debugging a computer program that includes a plurality of modules written in a plurality of languages, the method comprising the steps of: storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language: while a first machine is executing a first module of said plurality of modules that is written in the first language of said plurality of languages, using the mapping to generate debugging information about execution of said first module based on language constructs of the second language; and sending the debugging information to a debugger process designed for debugging programs written in the second language and not in said first language.

2. The method of claim 1, wherein the second language is JAVA and said step of using the mapping to generate the debugging information includes formatting the second debugging information according to JAVA Debug Wire Protocol (JDWP).

3. The method of claim 1, wherein the first language is PL/SQL.

4. The method of claim 1, said step of sending the debugging information to a debugger process further comprising sending the debugging information to a unifying component configured for sending integrated debugging information from a plurality of machines to the debugger process based on the debugging information.

5. The method of claim 4, wherein the method further comprises: while a second machine is executing a second module of the plurality of modules that is written in the second language of the plurality of languages, generating second debugging information based on language constructs of the second language; sending the second debugging information to the unifying component; and wherein the integrated debugging information is based on the debugging information and the second debugging information.

6. The method of claim 1, wherein the method further comprises: receiving a debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information from the first machine; and said step of generating debugging information is performed in response to said step of receiving the debugging request.

7. The method of claim 6, said step of receiving a debugging request based on the language constructs of the second language further comprising receiving the debugging request from a unifying component configured for dividing debugging requests from the debugging process among a plurality of machines that execute the plurality of modules.

8. The method of claim 1, wherein the debugging information indicates a stack of one or more instructions executed in order.

9. The method of claim 1, wherein the debugging information indicates tracing information that describes which groups of one or more instructions are executed.

10. The method of claim 1, wherein the debugging information indicates time profile information that describes execution time consumed by groups of one or more executed instructions.

11. The method of claim 1, wherein the debugging information indicates contents of a variable object based on executed instructions.

12. The method of claim 1, wherein the first machine is a virtual machine interpreting instructions that are not native to a physical processor.

13. The method of claim 1, wherein the first machine is a physical processor executing instructions native to the physical processor.

14. A method for debugging a computer program that includes a plurality of modules written in a plurality of languages, the method comprising the steps of: storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language; while a first machine is executing a first module of said plurality of modules that is written in the first language of said plurality of languages, generating first debugging information about execution of said first module based on language constructs of the first language; using the mapping to generate second debugging information based on the first debugging information, wherein the second debugging information is based on language constructs of the second language; and sending the second debugging information to a debugger process designed for debugging programs written in the second language and not in said first language.

15. The method of claim 14, wherein the second language is JAVA and said step of using the mapping to generate the second debugging information includes formatting the second debugging information according to JAVA Debug Wire Protocol (JDWP).

16. The method of claim 15, said step of generating first debugging information based on language constructs of the first language includes generating first debugging information based on language constructs of PL/SQL.

17. The method of claim 14, said step of sending the second debugging information to a debugger process further comprising sending the second debugging information to a unifying component configured for sending integrated debugging information to the debugger process based on the second debugging information.

18. The method of claim 17, wherein the method further comprises: while a second machine is executing a second module of the plurality of modules that is written in the second language of the plurality of languages, generating third debugging information based on language constructs of the second language; sending the third debugging information to the unifying component; and wherein the integrated debugging information is based on the second debugging information and the third debugging information.

19. The method of claim 14, wherein the method further comprises: receiving a first debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information from the first machine; using the mapping to generate a second debugging request based on the first debugging request, wherein the second debugging request is based on language constructs of the first language; and wherein said step of generating first debugging information is performed in response to said step of generating the second debugging request.

20. The method of claim 14, wherein the debugging information indicates a stack of one or more instructions executed in order.

21. The method of claim 14, wherein the debugging information indicates tracing information that describes which groups of one or more instructions are executed.

22. The method of claim 14, wherein the debugging information indicates time profile information that describes execution time consumed by groups of one or more executed instructions.

23. The method of claim 14, wherein the debugging information indicates contents of a variable object based on executed instructions.

24. A method for debugging a computer program that includes a plurality of modules written in a plurality of languages, the method comprising the steps of: Storing a mapping that maps between language constructs of a first language of the plurality of languages and language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language; receiving a first debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information about execution of a first module from a first machine configured for executing said first module of the plurality of modules that is written in the first language; using the mapping to generate a second debugging request based on the first debugging request, wherein the second debugging request is based on language constructs of the first language; and while the first machine is executing the first module, generating first debugging information based on language constructs of the first language.

25. The method of claim 24, further comprising: using the mapping to generate second debugging information based on the first debugging information, wherein the second debugging information is based on language constructs of the second language; and sending the second debugging information to a debugger process designed for debugging programs written in the second language.

26. A system for debugging a computer program that includes a plurality of modules written in a plurality of languages, the system comprising: a mapping that maps between language constructs of a first language of the plurality of languages and language constructs of a second language of the plurality of languages; a first machine of a plurality of machines, wherein the first machine is configured to execute a first module of the plurality of modules that is written in a first language of the plurality of languages and to generate first debugging information about execution of said first module based on language constructs of the first language; a second machine of the plurality of machines, wherein the second machine is configured to execute a second module of the plurality of modules that is written in a second language of the plurality of languages different than the first language and to generate, using said mapping, second debugging information about execution of said second module based on language constructs of the first language; a debugging process configured for sending requests for debugging information, for receiving debugging information, and for presenting debugging information to a user of the system; and a unifying component for sending each request from the debugging process to a particular machine of the plurality of machines, and for sending integrated debugging information to the debugging process that is based on the debugging information based on language constructs of the first language sent by the first machine and the second machine.

27. A computer-readable medium for debugging a computer program that includes a plurality of modules written in a plurality of languages, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of: storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language; while a first machine is executing a first module of said plurality of modules that is written in the first language of said plurality of languages, generating first debugging information about execution of said first module based on language constructs of the first language; using the mapping to generate second debugging information based on the first debugging information, wherein the second debugging information is based on language constructs of the second language; and sending the second debugging information to a debugger process designed for debugging programs written in the second language and not in said first language.

28. The computer-readable medium of claim 27, wherein the second language is JAVA and said step of using the mapping to generate the second debugging information includes formatting the second debugging information according to JAVA Debug Wire Protocol (JDWP).

29. The computer-readable medium of claim 28, said step of generating first debugging information based on language constructs of the first language includes generating first debugging information based on language constructs of PL/SQL.

30. The computer-readable medium of claim 27, said step of sending the second debugging information to a debugger process further comprising sending the second debugging information to a unifying component configured for sending integrated debugging information to the debugger process based on the second debugging information.

31. The computer-readable medium of claim 30, wherein: execution of the one or more sequences of instructions by one or more processors further causes the one or more processors to perform the steps of, while a second machine is executing a second module of the plurality of modules that is written in the second language of the plurality of languages, generating third debugging information based on language constructs of the second language, and sending the third debugging information to the unifying component; and said step of sending integrated debugging information is performed by sending integrated debugging information based on the second debugging information and the third debugging information.

32. The computer-readable medium of claim 27, wherein: execution of the one or more sequences of instructions by one or more processors further causes the one or more processors to perform the steps of: receiving a first debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information from the first machine; and using the mapping to generate a second debugging request based on the first debugging request, wherein the second debugging request is based on language constructs of the first language; and said step of generating first debugging information is performed in response to said step of generating the second debugging request.

33. A computer-readable medium for debugging a computer program that includes a plurality of modules written in a plurality of languages, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of: storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language; receiving a first debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information about execution of a first module from a first machine configured for executing said first module of the plurality of modules that is written in the first language; using the mapping to generate a second debugging request based on the first debugging request, wherein the second debugging request is based on language constructs of the first language; and while the first machine is executing the first module, generating first debugging information based on language constructs of the first language.

34. The computer-readable medium of claim 33, wherein execution of the one or more sequences of instructions by one or more processors further causes the one or more processors to perform the steps of: using the mapping to generate second debugging information based on the first debugging information, wherein the second debugging information is based on language constructs of the second language; and sending the second debugging information to a debugger process designed for debugging programs written in the second language.

35. A computer-readable medium for debugging a computer program that includes a plurality of modules written in a plurality of languages, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of: storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages; wherein said mapping includes at least one of: (a) a mapping between a program unit name used in the first language and a program unit name used in the second language, (b) a mapping between a routine name used in the first language and a routine name used in the second language, (c) a mapping between a variable name used in the first language and a variable name used in the second language, (d) a mapping between a type definition used in the first language and a type definition used in the second language; and while a first machine is executing a first module of said plurality of modules that is written in the first language of said plurality of languages, using the mapping to generate debugging information about execution of said first module based on language constructs of the second language; and sending the debugging information to a debugger process designed for debugging programs written in the second language and not in the first language.

36. The computer-readable medium of claim 35, wherein the second language is JAVA and said step of using the mapping to generate the debugging information includes formatting the second debugging information according to JAVA Debug Wire Protocol (JDWP).

37. The computer-readable medium of claim 35, wherein the first language is PL/SQL.

38. The computer-readable medium of claim 35, said step of sending the debugging information to a debugger process further comprising sending the debugging information to a unifying component configured for sending integrated debugging information from a plurality of machines to the debugger process based on the debugging information.

39. The computer-readable medium of claim 38, wherein: the execution of the one or more sequences of instructions by one or more processors further causes the one or more processors to perform the steps of, while a second machine is executing a second module of the plurality of modules that is written in the second language of the plurality of languages, generating second debugging information based on language constructs of the second language, and sending the second debugging information to the unifying component; and the integrated debugging information is based on the debugging information and the second debugging information.

40. The computer-readable medium of claim 35, wherein: execution of the one or more sequences of instructions by one or more processors further causes the one or more processors to perform the step of receiving a debugging request based on the language constructs of the second language, wherein the debugging request is for debugging information from the first machine; and said step of generating debugging information is performed in response to said step of receiving the debugging request.

41. The computer-readable medium of claim 40, said step of receiving a debugging request based on the language constructs of the second language further comprising receiving the debugging request from a unifying component configured for dividing debugging requests from the debugging process among a plurality of machines that execute the plurality of modules.

42. The computer-readable medium of claim 35, wherein the debugging information indicates a stack of one or more instructions executed in order.

43. The computer-readable medium of claim 35, wherein the debugging information indicates tracing information that describes which groups of one or more instructions are executed.

44. The computer-readable medium of claim 35, wherein the debugging information indicates time profile information that describes execution time consumed by groups of one or more executed instructions.

45. The computer-readable medium of claim 35, wherein the first machine is a virtual machine interpreting instructions that are not native to a physical processor.

46. The computer-readable medium of claim 35, wherein the first machine is a physical processor executing instructions native to the physical processor.

---

Description

---

FIELD OF THE INVENTION

The present invention relates to debugging a computer program. In particular, the present invention relates to debugging a computer program that is executed by multiple virtual machines.

BACKGROUND OF THE INVENTION

Computer programs are instructions for controlling processors in computing devices. Computer programs are typically written in one or more high level languages that are easy for a human being to understand. These source language statements are then typically compiled by a special type of program called a compiler and converted to coded instructions, which often correspond to the actual operations performed by a processor in a computer device. Frequently the coded instructions are not identical to the native instructions for the processor, but, instead, are instructions for a particular virtual machine. A virtual machine is a process that interprets coded instructions and executes them. The virtual machine itself is an executable sequence of instructions in the native language of the processor. Virtual machines are sometimes called interpreters. As used herein, the term "machines" includes virtual machines interpreting virtual machine instructions, operating systems interpreting operating system instructions, and processors executing native instructions.

An advantage of a virtual machine is that the same coded instructions for a particular virtual machine may be used on multiple computer devices built with different processors supporting different native instructions. The particular virtual machine is formed separately, using instructions from a different native instruction set for each different processor. Then, any program written in or compiled to the coded instructions for the particular virtual machine can be executed on any processor that executes the particular virtual machine. Examples of virtual machines include the JAVA virtual machine (JVM), the BASIC interpreter, the VisualBasic interpreter, and the interpreter for the PL/SQL language of the Oracle Corporation.

When a program is written or modified, it may be compiled successfully into coded instructions, and yet still not perform correctly when executed by the virtual machine. To assist a programmer in determining how the program executes differently than expected, debuggers have been developed for virtual machines. Debuggers are processes that provide functions that enable a programmer to determine the contents of computer memory at a time of execution for any instruction in one or more sequences of instructions.

Virtual machine debuggers typically include a debugger client process that interacts with an interface of the virtual machine. The debugger client process executes on a user's computing device that includes a display device. The debugger client process typically presents information about high-level language statements, and the contents of memory when the statements are executed. The debugger client process also includes controls that the user can operate to indicate which memory contents to display, and to indicate the next set of one or more instructions to execute before reporting the contents of memory, or to indicate a particular instruction at which execution is stopped and memory contents reported. In response to user actions, the debugger client process interacts with the debugger interface in the virtual machine. For example, the debugger client process sends a message to the virtual machine requesting that the virtual machine execute the next instruction and return the contents of one or more memory locations. As another example, the debugger client process invokes one or more routines of the virtual machine to execute the next instruction. As used herein, the term "routine" refers to a sequence of instructions ending in a return to a calling entity. Other terms commonly used for routines include "functions," "procedures," "methods," and "subroutines." The main block of code that is first executed for a program that often returns control to an operating system is also a routine. The debugger client process often presents to the user the context of program execution using a stack of routines that have been called but have not yet returned control to the calling routine.

In general, coded instructions from one or more modules can be linked to form an executable program. Modules can consist of source language statements, coded instructions for a particular virtual machine, runtime executables, or some combination of these, with or without associated data. Modules in a high-level source language may be compiled by a run time compiler to produce corresponding modules in coded instructions.

It is becoming more common to create programs that include heterogeneous modules. For example, a program may include a machine-executable module, a module executable by a first type of virtual machine, and a module executable by a second type of virtual machine. During execution of the program, a routine in the machine-executable module may call a routine in the module running in a first type of virtual machine, and that routine may call another routine in the module running in a second type of virtual machine.

In addition, it is common for programs executing on different processors to interact with each other. For example, a database application program, such as an accounting program, runs on one processor on one device on a network. However, while running, the accounting program may cause a database procedure, such as an average salary computation procedure, to be launched by a database server and run on a second processor on a different device on the network. Even if the database application program and the stored procedure are implemented with coded instructions for the same type of virtual machine (e.g. both programs are JAVA programs), each processor is running a separate instance of the particular virtual machine. In many situations, the interacting programs will not only be running on different virtual machines, but will employ coded instructions for different types of virtual machines (e.g. one will be a JAVA program, while the other is a Visual BASIC program).

While computer programs now often include multiple modules executed by different virtual machines or different instances of the same virtual machine, the debuggers currently available are typically not designed to handle these situations. For example, while the human user thinks about the program as a single entity, the program's execution is typically displayed as a series of separate stacks, one stack for each instance of each virtual machine.

A programmer who wants to trace the contents of memory while executing a set of instructions that spans two modules run on separate virtual machines usually operates separate debugger clients for the two modules and interacts separately with the two instances of the virtual machine. Memory contents could be manually copied from the user interface of one debugger client and inserted in the user interface of a separate debugger client. The manual process is tedious and subject to increased risk of human errors. The tedium and risk of error are multiplied as the number of separate interacting modules that are to be debugged increases.

Based on the foregoing, there is a clear need for a debugger process that presents debug information in an intuitive manner even for programs that include multiple modules executing on multiple virtual machines. As used herein, "multiple virtual machines" refers to multiple instances of the same virtual machine, virtual machines for different languages, or both.

SUMMARY OF THE INVENTION

Techniques are provided for debugging a computer program that includes multiple modules written in multiple languages. The techniques allow machines for the multiple languages to interface with a single debugger client using a standard interface.

In one aspect of the invention, the techniques include storing a mapping that maps language constructs of a first language of the plurality of languages into language constructs of a second language of the plurality of languages. While a virtual machine is executing a first module that is written in the first language, the mapping is used to generate debugging information based on language constructs of the second language. The debugging information is sent to a debugger process designed for debugging programs written in the second language.

In another aspect of the invention, the techniques include storing a mapping that maps language constructs of a first language into language constructs of a second language. While a first machine is executing a first module that is written in the first language, first debugging information is generated based on language constructs of the first language. The mapping is used to generate second debugging information based on the first debugging information. The second debugging information is based on language constructs of the second language. The second debugging information is sent to a debugger process designed for debugging programs written in the second language.

According to an embodiment of this aspect of the invention, the step of sending the second debugging information includes sending the second debugging information to a unifying component. The unifying component is configured for sending integrated debugging information to the debugger process based on the second debugging information and third debugging information from a second machine executing a module in the second language.

According to another aspect of the invention, techniques for debugging a computer program that includes multiple modules written in multiple languages include storing the mapping between the first language and the second language. A first debugging request is received based on the language constructs of the second language used by a debugger client. The first debugging request is for debugging information from a first machine configured for executing a first module that is written in the first language. The mapping is used to generate a second debugging request based on the first debugging request. The second debugging request is also based on language constructs of the first language. While the first machine is executing the first module, first debugging information based on language constructs of the first language is generated.

According to an embodiment of this aspect, the mapping is also used to generate second debugging information based on the first debugging information. The second debugging information is based on language constructs of the second language. The second debugging information is sent to a debugger process designed for debugging programs written in the second language.

These techniques allow a single debugger client designed for one language to present debugging information generated by a machine that executes a different language.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram of a system for unifying debugging information from multiple virtual machines according to an embodiment;

FIG. 2 is a block diagram illustrating program modules on a first program host, according to an embodiment;

FIG. 3 is a block diagram illustrating a stack of frames associated with routines having instructions corresponding to the program modules of FIG. 2, according to an embodiment;

FIG. 4 is a block diagram illustrating multiple language modules for a program on a first program host, according to an embodiment;

FIG. 5 is a block diagram illustrating a stack of frames associated with routines having instructions corresponding to the multiple language modules of FIG. 5, according to an embodiment;

FIG. 6A is a flowchart illustrating at a high level a method for debugging a computer program having multiple modules executed by multiple virtual machines according to an embodiment;

FIG. 6B is a flowchart illustrating a method at a unifying process for debugging a computer program executed by multiple virtual machines based on a message from a debugger client, according to an embodiment;

FIG. 6C and FIG. 6D make up a flowchart illustrating a method at a unifying process for debugging a computer program executed by multiple virtual machines based on a message from a virtual machine, according to an embodiment

FIG. 7 is a block diagram illustrating a modified virtual machine, according to an embodiment;

FIG. 8 is a flowchart illustrating a method for debugging a computer program having multiple language modules executed by multiple virtual machines according to an embodiment;

FIG. 9 is a block diagram illustrating multiple tier program modules on multiple hosts, according to an embodiment; and

FIG. 10 is a block diagram that illustrates a computer system 1000 upon which an embodiment of the invention may be implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A method and apparatus for debugging computer programs involving multiple virtual machines is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. For example, embodiments of the invention are described below in the context of multiple virtual machines; however, other embodiments of the invention may involve a machine executing instructions native to a processor, or a machine executing operating system instructions, in place of one, several, or all of the virtual machines. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Structural Overview

FIG. 1 is a block diagram of a system for unifying debugging information from multiple virtual machines according to an embodiment. A multiple module program executes on one or more program hosts 110, for example to provide a service over a network. The program modules 130 are stored on the program hosts 110. For example, a JAVA program is made up of JAVA modules stored in modules 130 for the program. The program modules 130 are executed by multiple virtual machines, for example, first virtual machine 121, second virtual machine 122, and third virtual machine 123.

The system also includes a debugger client 102 executing on a debugger client host 104. The debugger client 102 includes an interface 152a for communicating with the virtual machines 121, 122, 123. The virtual machines 121, 122, 123 include interfaces 154a, 154c, 154d, respectively, for communicating with a debugger client. The debugger client and the interfaces are described in more detail in a later section.

Embodiments of the present invention include a unifying process 142 for mitigating communications among the debugger client 102 and the virtual machines 121, 122, 123. The unifying process includes an interface 152b and an interface 154b. Hereinafter the interfaces 152a, 152b are collectively referenced as interface 152, and interfaces 154a, 154b, 154c, 154d are collectively referenced as interface 154. The unifying process is described in more detail in a later section.

Debugging Overview

When the program is debugged, a virtual machine 121 that interprets coded instruction modules of the stored modules 130 is run in a debug mode. When running in a debug mode, the virtual machine 121 interacts with the debugger client 102 on the debugger client host 104. The debugger client 102 typically includes a user interface (not shown) that displays information about the program that is being debugged and provides controls for a user to control the execution of the program. For example, the user may specify, through the controls provided by the user interface of the debugger, one or more breakpoints. A breakpoint identifies a location within the program at which execution should halt. Halting a program at a breakpoint gives the user time to inspect the debug information at that particular point of execution. The user typically specifies a breakpoint by selecting an instruction in the high-level language code that was used to generate the program. The execution of the program halts after executing the lower-language code that corresponds to the selected higher-language instruction.

As a more specific example, the user is prompted to specify one or more JAVA statements to serve as execution breakpoints and to specify one or more JAVA objects or attributes whose contents are of interest. The debugger client 102 sends messages to the virtual machine 121. The commands include the information to control execution of the modules, such as the breakpoints and memory locations of interest. The virtual machine 121 executes the coded instructions of one or more modules until a breakpoint is reached. The virtual machine 121 reports that the breakpoint is reached in a message containing debugging information to the client 102. If the user has not already done so, the user then specifies a next debugging operation to perform, such as executing the next statement in the program, or reporting the contents of one or more memory locations of the virtual machine 121. The virtual machine 121 retrieves the contents of the specified memory locations at that stage of execution, and sends a report message including more debugging information back to the debugger client 102. The debugging information includes the memory contents. The debugger client 102 presents the results, usually in association with the instruction in the high-level language that corresponds to the breakpoint.

As used herein, debugging information is information based on data provided by one or more virtual machines, which is utilized by a user of client 102 to assess the performance of a computer program. Debugging information includes, for example, contents of memory locations at a particular stage of execution, a call stack of virtual machines or routines that have been invoked but not yet ended at the particular stage of execution, lists of objects associated with one or more routines or virtual machines, tracing information, and time profile information, among others. Tracing information describes which groups of one or more instructions are executed. The groups may be modules or routines, for example. Time profile information describes execution time consumed by groups of one or more executed instructions.

The debugger client often provides the user with information about the call stack of the virtual machine, which provides context for the state of the program execution at the time the breakpoint is encountered. A call stack is often presented as a series of frames representing calls to routines that have not yet returned. The frames are positioned in the stack in order of execution. A frame in the stack is often expressed by the statement in the high-level language that calls the routine or the name of the routine. The stack helps a user to identify where in the execution of the program the current memory contents occur.

Inter-Component Communications

The debugger client 102 and virtual machine 121 are designed to exchange commands and responses through interface 152a on the debugger and complementary interface 154a on the virtual machine. Any manner known in the art for an interface may be employed. In some embodiments, an interface is a specified set of procedure calls that include specification of a procedure name, and specification of number and types of parameters passed to the procedure and returned from the procedure. In such embodiments, the debugger client typically is executed on the same host as the virtual machine rather than on different host as depicted in FIG. 1. The set of procedures that can be invoked in the virtual machine make up the virtual machine interface 154a, and the set of procedures that can be invoked in the debugger client make up the debugger client interface 152a.

In some embodiments, an interface is a protocol for exchanging debugging information using data packets transmitted over a network. For example, for a JAVA virtual machine, the JAVA Debug Wire Protocol (JDWP) has been defined for exchanging debugging information between processes. JDWP may be used to transmit debugging information over the Transport Control Protocol of the Internet Protocol (TCP/IP), or over any other network protocol, or through pipes or shared memory. JDWP may also be used to pass information between parts of the same process using memory-based mechanisms. At the time of this writing, JDWP is described in file jdwp-spec.html on directory j2se/1.3/docs/guide/jpda at Internet domain java.sun.com. Such protocols allow the debugger client 102 to reside on a different host 104 from the host 110 where the virtual machine 121 that is executing the module being debugged resides. In this case, the virtual machine interface 154a represents procedures that process the types of information passed to the virtual machine according to the protocol, and procedures that produce messages for the debugger client according to the protocol. Similarly, the debugger client interface 152a represents procedures that process the types of information passed to the debugger client according to the protocol, and procedures that produce messages for the virtual machine according to the protocol.

The Unifier Process

According to embodiments of the invention, a unifying process 142 is interposed between the debugger client 102 and the virtual machine 121. To the debugger client 102, the unifying process 142 appears to be a virtual machine by virtue of the virtual machine interface 154b. To the virtual machine 121, the unifying process 142 appears to be a debugger client by virtue of the debugger client interface 152b. The unifying process 142 produces integrated debugging information for presentation at the debugger client 102, no matter which virtual machines execute different modules of the program, as described in more detail in a later section. Although shown as a separate process in FIG. 1, in some embodiments the unifying process 142 is merely a component of one or more of the other processes, such as the processes that implement the debugger client 102, the virtual machine 121, a development editor (not shown) or a database server (not shown).

Also shown in FIG. 1, are a second virtual machine 122 with a virtual machine interface 154c and a third virtual machine 123 with a virtual machine interface 154d. Depending on the nature of the application being executed, the second and third virtual machines may execute at overlapping times relative to the first virtual machine 121.

For example, a JAVA module executing on a first JAVA virtual machine may invoke a procedure from a second JAVA module that may be executed by a second instance of the JAVA virtual machine on a second host. After control returns from the called procedure of the second module, the first JAVA module may then invoke the same or a different procedure that starts a third instance of the JAVA virtual machine. On a host with multiple processors, the two or three JAVA virtual machines might execute on separate processors of the same host. On some hosts, multiprocessing is performed by sharing time on the same one or more processors. If the calling module waits for the response from the called module before proceeding, the call is said to be synchronous. The unifying process is configured to provide debugging information with respect to a single stack of frames for all modules involved in a series of synchronous calls. In some embodiments, the unifying process is also configured, to provide debugging information as separate stacks ("threads") for any part of the program invoked by asynchronous calls.

In another example, different virtual machines are executed to interpret modules in different languages that produce different types of coded instructions. For example, a JAVA procedure invoked from a database may include an SQL statement. The JAVA virtual machine is executing to interpret the JVM coded instructions (bytecode). To interpret the embedded SQL statement, an SQL virtual machine is executed. The SQL statement may include an operation that triggers a procedure call for a module written in PL/SQL; so a PL/SQL virtual machine is executed to interpret the PL/SQL statements of the PL/SQL module.

According to embodiments of the invention, the second and third virtual machines, 122, 123 communicate with the unifying process 142, as does the first virtual machine 121. In FIG. 1 the three virtual machines communicate with the unifying process 142 through the same debugger client interface 152b of the unifying process, as described in more detail below. In other embodiments, the virtual machines of different languages communicate through different debugger client interfaces. Although three virtual machines are depicted exchanging debugging information with the unifying process in FIG. 1, in other embodiments, the unifying process 142 may exchange debugging information with more or fewer virtual machines.

Although the virtual machines 121, 122, 123 are shown executing on the program hosts 110, in other embodiments, one or more of the virtual machines can execute instead on any host that includes either direct or remote access to an appropriate subset of the modules 130 to be executed by the virtual machine.

Furthermore, although the unifying process 142 is depicted in FIG. 1 as residing on the same hosts where the virtual machines reside, embodiments that use a network protocol for the interfaces allow the unifying process to reside on any host on the network.

Debugging with Multiple Instances of the Same Virtual Machine

To illustrate the behavior of the unifying process with multiple instances of the same virtual machine, it is assumed that the modules 130 for the program are distributed over several program hosts. It is further assumed that the first virtual machine 121 is a first instance of a virtual machine, such as a JVM, that executes on a first program host, and that the second virtual machine 122 is a second instance of the same virtual machine, such as another JVM, that executes on a second program host.

FIG. 2 is a block diagram illustrating program modules 230 on the first program host, according to an embodiment. The modules 230 include modules of coded instructions based on an A module 240 and a B module 260 of statements in the same high-level language. For example, the modules 230 include JAVA classfiles of JAVA bytecode based on an A module 240 of statements in the JAVA language and a B module 260 of statements in the JAVA language.

Any method may be used to associate high-level language statements depicted in FIG. 2, with the coded instructions actually interpreted by the virtual machine. In some embodiments, the coded instructions are determined from the source code by compiling just before the virtual machine executes the coded instructions. In other embodiments, the high-level language statements are compiled into coded instructions ahead of time, but pointers relate coded instructions to the associated high-level language statement.

The A module 240 includes statements 242, 243, 244, 245, 246 in the high-level language that define a routine X. The A module 240 may also include other statements represented by the ellipses 241, 247 that are not relevant to illustrating an embodiment of the invention.

The B module 260 includes statements 262, 263, 264, 265, 266 in the high-level language that defines a routine Y. The B module 260 may also include other statements represented by the ellipses 261, 267 that are not relevant to illustrating an embodiment of the invention.

In the illustrated embodiment, the routine X starts in statement 242, includes other statements represented by the ellipsis 243, and then includes a statement 244 to invoke routine Y of the B module. For example, a JAVA statement to invoke a routine Y (a JAVA static method) in a JAVA class named "ClassQ" in the B package could be of the form:

B.ClassQ.Y( ),

where the empty parentheses indicate that no parameters are passed to this particular routine. Routine X continues with other statements represented by the ellipsis 245. Routine X ends with statement 246, which causes the virtual machine to return control to whatever entity invoked the routine X.

In the illustrated embodiment, the routine Y starts in statement 262, includes other statements represented by the ellipsis 263, and then includes a statement 264 to invoke routine Z of a C module on another host. Routine Y continues with other statements represented by the ellipsis 265. Routine Y ends with statement 266, which causes the virtual machine to return control to whatever routine called routine Y. For example, when routine X invokes the routine Y, control is returned to routine X after the virtual machine executes all the statements in routine Y. Invoking a routine in the module C on a remote host involves communication from the first virtual machine 121 that executes the coded instructions for the A module and the B module to the second virtual machine 122 on the remote host that executes the coded instructions for the C module. Any method known in the art to provide the information and establish the connection may be used.

FIG. 2 also illustrates frames. A frame is a level of execution within a program. A frame is added to a stack of frames whenever an instruction that invokes another routine is executed by a virtual machine. A frame is removed from a stack when the routine returns control to the calling program. For example, frame 252 is formed when Routine X is executed, and Frame 272 is formed when Routine Y is executed. Frame 272 is removed when the statement 266 that ends routine Y is executed, and frame 252 is removed when the statement that ends routine X is executed. If a routine is called recursively, that routine may form several frames during execution.

FIG. 3 is a block diagram illustrating a stack 330, desired by a user, for a breakpoint encountered while routine Z is executing. To demonstrate the state of execution while routine Z is executing, all the statements of the routines that have been executed are shown in each frame in FIG. 3. However, the frame is usually specified simply by the name of the routine whose invocation created the frame on the stack, not by the complete listing of statements in the routine. Thus Frame 252 is usually specified as the frame representing the call to Routine X. The frame information usually includes not only the name of the routine invoked but also the position in the invoking routine where the invocation is made. Such a position is the "current position" in the invoking routine. The current position can be specified in any manner known in the art. For example, in one embodiment, a program counter specifies the position. In another embodiment, a statement number specifies the current position.

The stack 330 includes frames 252, 272 representing invocations of routines X and Y, respectively, from the modules on the first host and includes a frame 380 representing the invocation of routine Z of module C on the second host. Ellipsis 332 represents frames for routines executed before routine X is invoked. Frame 380 represents routine Z having statements 381, 383, 388 in the high-level language that have been executed before the breakpoint. The routine Z starts in statement 381, includes other statements represented by the ellipsis 383, and ends at the last statement 388. For purposes of illustration, it is assumed that the breakpoint was selected after the last statement 388, just before exit of routine Z. Therefore frame 380 is the last frame in the stack. In embodiments in which the breakpoint is in another routine invoked directly or indirectly by Routine Z, subsequent frames, represented by ellipsis 338, follow frame 380.

Unified stack 330 represents call information in a manner consistent with how users think about the program that is being debugged. Specifically, users typically consider the program as a single process involving a sequence of calls, not as a complex web of interactions between disparate modules executing in separate processes. Using the unified stack 330, a user can easily determine the contents of variables in routines X, Y, and Z at the stage when the breakpoint statement is executed. The user can also set the contents of those variables to different values.

However, using conventional virtual machines 121, 122, and a single debugger client 102 without a unifying process 142, the frame 380 of instructions executed on the remote host would not be displayed after frames 252 and 272 by the debugger client 102 communicating with the first virtual machine 121. The user would not be able to use debugger client 102 for setting or reporting contents of variables in Routine Z associated with frame 380. Instead, the user would ordinarily execute a second debugger client (not shown) that communicates with the second virtual machine 122. Frame 380 may then be indicated in a graphical user interface of the second debugger client. The user would have to switch back and forth between the first debugger client 102 and the second debugger client to debug across the boundary between routine Y and routine Z. Such switching is slow and tedious