Abstract:
A system and method for managing the environment of software processes in a computer system. A computer system comprises a processor and at least one process environment comprising one or more environment variables. The processor executes one or more processes, intercepts the launch of a process, sets at least one environment variable to a first value, and continues the launch of the process. Setting the environment variable may enable a profiler process. The processor may set at least one environment variable for the process to a value which is chosen irrespective of a value of the environment variable of a parent process of the process. Further, the processor may set at least one environment variable for the process to a default value if a data repository does not contain an entry that has an identification which corresponds to the process.

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   This invention relates to computer processes and, more particularly, to managing the profiling of processes. 
   2. Description of the Related Art 
   In order to gain a fuller understanding of the operation of software processes, it is common to employ any of a variety of monitoring, profiling, and/or analysis programs in conjunction with the software processes to be understood. Such monitoring, profiling, and analysis programs which, for simplicity, may collectively be referred to as “profilers”, are available from many vendors or may be custom-made for specific applications. It is generally desirable to be able to profile selected processes as well as to select specific profilers to operate with selected processes. Therefore, some mechanism for identifying processes and profilers and associating one with the other may be desired. Existing operating system software may provide environment variables through which profiling and profiling processes may be specified. However, each process may have its own individually set environment variables, the values of which may be determined by the process itself or a parent process from which the profiled process is launched. Since the profiled process and the profiler may be written by different programmers or come from different vendors, the environment variable settings of any given process may not conform to the settings desired by the profiler. 
   For example, software systems such as Microsoft&#39;s .NET® framework and Windows® operating system may enable programs and processes to provide dynamic and interactive web pages such as Active Server Pages (ASP). As applications and processes based on .NET technology proliferate, the desire to monitor and profile the operation of these applications and processes has increased. The .NET framework includes a profiling Application Program Interface (API) which allows application programmers to write an application (e.g., a “profiler”) that can monitor the operation of applications running within the .NET framework. Such a profiler may monitor resource usage, interactions between processes and the operating system or the .NET framework, exception handling, etc. 
   To enable a profiler to monitor a process, the .NET profiling API uses environment variables (sometimes referred to as “envars”) that are provided by the underlying operating system. One environment variable, COR_ENABLE_PROFILING may be used to determine whether profiling is enabled. A second environment variable, COR_PROFILER may be used to specify a particular profiler to be used. The values of these environment variables at the time the process is launched determine if and how the process will be profiled. In the case of applications for which the source code is readily available and may be modified, the program may set the environment variables itself. However, in many cases it is difficult to change the environment variables between process launches. For example, a system reboot may be required to have new environment variable settings take effect if the process is a system service. Also, the source code for a given application (e.g., third party applications) may not be available. Consequently, it may not be possible, or practical, to modify an application to set particular environment variables. 
   Consequently, a method and mechanism for managing the environment variables and the profiling of processes is desired. 
   SUMMARY OF THE INVENTION 
   Various embodiments of a system and method are disclosed. In one embodiment, a computer system comprises a processor and at least one process environment comprising one or more environment variables. The processor is configured to execute one or more processes, intercept the launch of a first process, set at least one environment variable of the environment variables to a first value, and continue the launch of the first process. 
   In a further embodiment, setting the environment variable enables a profiler. In a still further embodiment, the processor is configured to enable profiling in response to detecting that the at least one environment variable has a first value and disable profiling in response to detecting that the at least one environment variable has a second value or is not set. 
   In a still further embodiment, the processor is configured to set at least one environment variable for the first process to a value which is chosen irrespective of a value of the at least one environment variable of a parent process of the first process. In a still further embodiment, the processor is configured to set at least one environment variable for the first process to a default value, responsive to detecting that the data repository does not contain an entry that has an identification which corresponds to the first process 
   These and other embodiments will become apparent upon reference to the following description and accompanying figures. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  illustrates one embodiment of a computer including a processor. 
       FIG. 2  illustrates one embodiment of components of a software system in which system software may establish an environment in which software processes may operate. 
       FIG. 3  illustrates one embodiment of a process for managing the environment of a software process. 
       FIG. 4  illustrates one embodiment of components of a software system. 
       FIG. 5  illustrates one embodiment of a process for loading environment variables from a configuration file for a software process. 
   

   While the invention is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed descriptions thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. 
   DETAILED DESCRIPTION 
   The following description is presented to enable one of ordinary skill in the art to make and use the invention. Descriptions of specific embodiments and applications are provided only as examples and various modifications will be readily apparent to those skilled in the art. The general principles described herein may be applied to other embodiments and applications without departing from the scope of the invention. Thus, the present invention is not to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein. 
     FIG. 1  illustrates one embodiment of a computer  110  including a processor  120 . Processor  120  is shown coupled through an interconnect  130  to a non-volatile storage  140 , an I/O controller  150 , and a memory  160 . I/O controller  150  may be coupled to a display  170 , a keyboard  180 , and a mouse  190 . A variety of other peripheral devices such as boot devices and network interfaces may be coupled to I/O controller  150  as well as or instead of those described above. In addition, interconnect  130  may couple a variety of other devices to processor  120  depending on the desired functionality of computer  110 . 
   Processor  120  may be configured to execute instructions and to process data according to a particular instruction set architecture (ISA). In one embodiment, processor  120  may be configured to implement an x86 compatible ISA, although in other embodiments it is contemplated that any desired ISA may be employed, such as the SPARC V9 ISA, PowerPC compatible ISAs, or MIPS compatible ISAs, for example. (SPARC is a registered trademark of Sun Microsystems, Inc.; PowerPC is a registered trademark of International Business Machines Corporation; MIPS is a registered trademark of MIPS Computer Systems, Inc.). 
   In various embodiments, memory  160  may comprise any suitable type of system memory as described above, such as FB-DIMM, DDR/DDR2 SDRAM, or RDRAM®, for example. Memory  160  may include multiple discrete banks of memory. Also, in some embodiments memory  160  may include multiple different types of memory. 
   In some embodiments, computer  110  may include more than one instance of the devices shown, such as more than one processor  120 , for example. In various embodiments, computer  110  may be configured as a rack-mountable server system, a standalone system, or in any other suitable form factor. In some embodiments, computer  110  may be configured as a client system rather than a server system. 
   In one embodiment, processor  120  may be configured to run operating system software such as Microsoft Windows, IBM AIX or Sun Microsystems Solaris. Operating system software may in turn provide an environment in which processor  120  may execute additional software modules in the form of applications, programs, or processes designed to perform specific functions. Running operating system software or software modules may comprise executing instructions that are stored in memory  160 . 
   Software modules that may be executed by processor  120  may include, in one embodiment, client/server software such as a web server or a web browser. Alternatively, or in addition, processor  120  may execute software modules comprising network management software, office productivity tools, e-mail programs, etc. Many other types of software may be executed such as a virtual machine runtime environment, a database, an application server, and diagnostic, monitoring, profiling, or analysis software. Furthermore, while executing such software, processor  120  may retrieve data from and store data in non-volatile storage  140  or in memory  160 . In one embodiment, one or more software processes may perform the function of profiling other software processes during operation, gathering and storing data indicative of the operation of one or more of the other software processes. Alternatively, profiling of a process may be achieved by linking a profiling library into the target process itself. 
     FIG. 2  illustrates one embodiment of components of a software system in which system software  210  may establish an environment  212  in which software processes may operate. In the illustrated embodiment, system software  210  may run on processor  120  along with and in support of a process  220  and a process  230 . System software  210  may include a launch interception process  214 , which in turn may include a file transfer process  216 . Also shown is a configuration file  240  whose function is described below. 
   During operation, environment  212  may affect the execution of process  220  in a variety of ways. For instance, environment  212  may specify the location of data storage to be used by process  220 . Alternatively, or in addition, environment  212  may specify a level of debugging support to be implemented while process  220  is operating. Also, environment  212  may specify whether or not various auxiliary processes may operate in conjunction with process  220 . For example, in one embodiment, environment  212  may specify that a profiler may be linked to process  220  as a dynamic link library (DLL), to monitor and gather statistical data related to the use of system resources, exception generation, interaction with other processes, method invocation, performance metrics, or any other profiling data for process  220 . In an alternative embodiment, environment  212  may specify that process  230  may be launched in conjunction with the launch of process  220 , to profile process  220 . 
   In the embodiment shown in  FIG. 2 , system software  210  may take a snapshot of the settings of environment  212  that affect the operation of process  220  at the time process  220  is launched. Subsequently, other processes may be launched and other snapshots of environment  212  that are different from those that apply to process  220  may be established. Different processes may have different settings for environment  212  that may be set by a parent process or other high-level software modules such as an application server prior to process launch. In one embodiment, the parent process which sets the values of environment  212  for process  220  is the process which spawns process  220 . However, it may be desired to change environment  212  for a given process according to settings that are different from those set by the parent process or other high-level software module. In normal operation, system software  210  may provide a “local” environment for a newly launched process  220  that is inherited from the parent process of process  220 . Various difficulties stand in the way of modifying the environment settings for a process after it is launched. For example, if process  220  is a system service, then system software  210  may require a system reboot before new environment settings take effect. However, rebooting a system may be undesirable due to the time involved and the effect on other processes that may be running at the same time. Also, the parent process that establishes the environment settings for process  220  may be part of a third-party application that was not written with the capability of modifying environment settings and whose code is not easily enhanced by the user. Consequently, the parent process of process  220  may not be capable of modifying the environment settings as desired by the user of process  220 . 
   In one embodiment, it may be desired to modify the local environment of a process (e.g., an environment inherited from a parent process) with one or more overriding “global” environment settings. In order to modify the settings of environment  212  for a given process, processor  120  may take advantage of a launch interception process  214  provided by system software  210 . In operation, launch interception process  214  may detect a process launch and cause process  216  to retrieve environment settings (e.g., from a configuration file  240 ). In alternative embodiments, values of environment variables may be retrieved from one of a variety of data repositories other than a configuration file. For example, environment variable values may be retrieved from a system registry, retrieved by querying a remote server, or any other suitable means. In the following discussion, whenever environment settings are described as being retrieved from configuration file  240 , it is assumed that each of these alternatives or other alternatives are also possible and are contemplated. 
   Once the values of the retrieved environment settings have been retrieved, they may be applied to process  220 . Having thus established environment  212 , the launch may be completed. For example, the local environment associated with the parent process of process  220  may specify that profiling be disabled while global values in configuration file  240  may specify that process  220  is to be profiled and may identify a particular profiler to be used. When process  220  is launched, launch interception process  214  may detect the launch, process  216  may read environment settings for process  220  from configuration file  240  and transfer the settings to environment  212 , including a setting specifying that a particular profiling DLL be linked to process  220 . Alternatively, the local environment associated with the parent process of process  220  may specify that profiling be enabled while global values in configuration file  240  may specify that profiling be disabled for process  240 . In that case, when process  220  is launched, launch interception process  214  may detect the launch, process  216  may read environment settings for process  220  from configuration file  240  and transfer the settings to environment  212 , including a setting specifying that profiling be disabled for process  240 . In the case of any local and global environment settings that are the same, the functions performed by launch interception process  214  and process  216  may not change those environment settings. System software  210  may, in one embodiment, ensure that the modification of environment  212  by launch interception process  214  is completed before other processes that utilize environment  212  settings become operational. 
   Separate environment settings may be established for any number of processes in this manner. Any process for which the launch may be intercepted by launch interception process  214  may receive its own environment  212 . In one embodiment, configuration file  240  may contain a list of one or more processes identified by name, or some other identifying attribute, along with corresponding environment settings desired for each process in the list. A process for which a name or other identifying attribute is not included in the configuration file  240  may receive certain default settings. For example, process  216  may be configured to apply default settings (which may comprise system-wide default settings) to environment  212  for a process that is omitted from the list of configuration file  240 . Alternatively, process  216  may be configured to simply ignore environment settings for a process that is not identified in configuration file  240 . In an alternative embodiment, although a given process may be identified in configuration file  240 , one or more environment variables may be omitted from the entry corresponding to the given process. In that case, process  216  may be configured to apply default settings to environment  212  or ignore environment settings for the given process, that is, for a process for which a value of an environment variable is not set. 
     FIG. 3  illustrates an overview of one embodiment of a process  300  for managing the environment of a software process. Process  300  begins by detecting the start of a process launch (block  310 ). Upon detecting a process launch, environment settings may be retrieved from a configuration file (block  320 ). If the retrieved environment settings for the process do not specify that the local environment settings are to be overridden (decision block  330 ), then the process launch may be completed with no change to the environment settings (block  350 ). In an alternative embodiment, if an entry corresponding to the process being launched is not present in the configuration file, then environment settings for the process may be cleared or otherwise set to predetermined default values. If the retrieved environment settings for the process specify that the local environment settings are to be overridden (decision block  330 ), then the retrieved environment settings may be implemented (block  340 ) prior to completion of the process launch (block  350 ). 
     FIG. 4  illustrates one embodiment of components of a software system based on Microsoft Windows and Microsoft .NET in which the environment of a software processes may be managed including profiling of the process. While the Microsoft Windows operating system and .NET framework are utilized for purposes of discussion, the methods and mechanisms described herein may be applied in other environments as well. In the illustrated embodiment, a process  410  and a profiler  420  are shown coupled to a .NET framework  450  supported by a Windows operating system (Windows)  430 . 
   Also shown are a configuration file  480  and a log file  490 . Process  410  may be, for example, an active server page (ASP) conforming to the ASP.NET specification. Windows  430  may be one of Windows 98, Windows 2000, Windows XP, or any other version of the Windows operating system with which .NET framework  450  is compatible. In one embodiment, .NET framework  450  includes a .NET profiling application programming interface (API)  455 . Profiler  420  may be a DLL written to use the functionality provided by the .NET profiling API  455  and configured to profile process  410 . 
   As further illustrated in  FIG. 4 , Windows  430  may include environment variables (envars)  440 , a User32.dll  460 , and a list of AppInit_DLLs  470 . Envars  440  are environment variables used by Windows  430  to establish an operating environment for each process that is launched. User32.dll is a dynamic link library that may be linked to user defined processes at the time of launch, such as process  410 , that utilize the Windows user interface functionality. 
   In operation, during the launch of process  410 , Windows  430  may assemble various files with process  410  into an executable file or library in a procedure referred to as dynamic linking. Specifically, in one embodiment, Windows  430  may link process  410  to User32.dll  460 . As part of the linking procedure for a windows process, User32.dll  460  may execute a process known as DLL_PROCESS_ATTACH that includes execution of a “LoadLibrary( )” function. LoadLibrary may load and initialize DLLs that are listed in AppInit_DLLs  470 . Appinit_DLLS  470  may include user specified DLLs  471 ,  472 ,  473 , etc., that may be dynamically linked to a process during initialization. In the illustrated embodiment, one of the Appinit_DLLs is an interception.dll  473 . Interception.dll  473  may be configured to read a set of values for environment variables  440  from configuration file  480  and set the environment variables  440  for process  410  according to these values. Two environment variables in particular may control profiling of process  410 . The first, COR_ENABLE_PROFILING, enables or disables profiling of process  410 . For example, setting COR_ENABLE_PROFILING may enable profiling and clearing COR_ENABLE_PROFILING may disable profiling. The second, COR_PROFILER, may be used to identify a particular profiler, such as profiler  420 , which is to be linked to and used for profiling process  410 . Accordingly, interception.dll  473  may retrieve and set values for environment variables COR_ENABLE_PROFILING and COR_PROFILER that apply to process  410  during the launch procedure. 
   It is noted that changing the value of COR_PROFILER may enable an application to override one profiler with another profiler or select a profiler based on the data collected by another profiler. It is further noted that in various embodiments, selected profiling environment variables may be either set or cleared by default on a system wide basis and then overridden for one or more specific processes via entries in configuration file  480 . Once profiling of process  410  has been enabled and the launch of process  410  completed, profiler  420  may store profile data for process  410  in a log file  490 . 
   In one embodiment, interception.dll  473  may consult configuration file  480  during the launch of tens or even hundreds of processes. In order to avoid the delay of reading from non-volatile storage, Windows  430  may maintain a copy of configuration file  480  in memory for faster access. 
     FIG. 5  illustrates one embodiment of a process  500  for setting environment variables based on values in a configuration file for a .NET software process. Process  500  begins when a process launch is detected. A list of DLLs to be linked to the process being launched may be obtained from Appinit_DLLs (block  510 ). One of the listed DLLs, interception.dll, may be linked to the launched process (block  520 ). Subsequently, interception.dll may be initialized (block  530 ). During initialization, interception.dll may read environment variables settings for the launched process from a configuration file (block  540 ) and set the environment variables using the retrieved settings (block  550 ). After the environment variables have been set, the process launch may be continued. 
   In alternative embodiments, process launch may be intercepted and environment variables set by a variety of mechanisms other than using AppInit_DLLs. For example, any operating system kernel-level interception mechanism such as those used by virus detection software may be used. Alternatively, a higher level process launch interception mechanism may be used. 
   It is noted that the above described embodiments may comprise software. In such an embodiment, the program instructions which implement the methods and/or mechanisms may be conveyed or stored on a computer readable medium. Numerous types of media which are configured to store program instructions are available and include hard disks, floppy disks, CD-ROM, DVD, flash memory, Programmable ROMs (PROM), random access memory (RAM), and various other forms of volatile or non-volatile storage. 
   Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.