Remote monitoring of local behavior of network applications

BACKGROUND

p-0002Traditionally, software, in the form of computer-executable instructions embodied on a computer-readable medium, has been distributed by providing users with a single version of such software through a compact disk (CD) or other computer-readable medium that simultaneously comprises all of the software's computer-executable instructions. Such distribution mechanisms required specific update cycles, where new versions of software were released by announcing their availability and requiring existing users to obtain new CDs or other computer-readable media.

p-0003An increasingly popular method of software distribution, however, eschews computer-readable media that simultaneously comprise all of the software's computer-executable instructions in favor of computer-readable media, such as computer networking hardware and connections that deliver the software's computer-executable instructions to a user on an as-needed basis. Such real-time delivery of computer software enables developers to continuously update their software, and allows users to continuously obtain the most up-to-date version. In particular, the software, and distribution environment can be such that the user must obtain the computer-executable instructions from a centralized location each time the user executes the software. In addition, the nature of the software's delivery encourages the use of distributed computing techniques, whereby one or more components of the software would be executing on the user's computing device, while one or more other components of the software would be executing on a centralized server computing device remote from the user's computing device.

p-0004Often, software that is delivered using real-time distribution mechanisms seeks to provide platform-independent functionality. For example, one environment in which real-time distribution of software is prevalent is the World-Wide Web (WWW), where software comprises both computer-executable instructions executing on a server computing device and, operating in concert, scripts that are downloaded by and executed by a web browser. Because web browsers exist for a variety of hardware and software platforms, including computing devices based on differing microprocessor architectures and computing devices executing differing operating systems, software that is incompatible with one or more of these platforms risks losing popularity by immediately excluding some percentage of users. Consequently, web-based software delivered in a real-time manner generally seeks to provide functionality for users of multiple computing platforms. Unfortunately, because of the heterogeneity of client computing devices, the developers of software delivered in a real-time manner can be handicapped when attempting to test their software in a manner approximating an expected range of usage once deployed.

p-0005As software delivered in a real-time manner increases in complexity, it is not just the heterogeneity of client computing devices that can cause difficulties for the developers of such software. Other factors, such as the workload generated by the software, or its dependence on third-party services and networks, can likewise render the creation and maintenance of such software more difficult.

SUMMARY

p-0006To observe and monitor the behavior of computer-executable instructions provided to, and executed on, a client computing device, additional monitoring instructions can be added to the computer-executable instructions to record specific events or other information and then return such information. In one embodiment, a modifying component can intercept instructions being delivered from a server computing device to a client computing device, and can add additional monitoring instructions to the intercepted instructions. Information collected by such monitoring instructions can be returned to the modifying component, or associated elements, and can be used to inform future modifications of the same intercepted instructions when requested again by a client. In an alternative embodiment, the modifying component can add monitoring instructions in such a manner that each client receives only a portion of the overall monitoring being performed with respect to the intercepted instructions.

p-0007The modifying component can, in one embodiment, comprise a parser that can identify elements within the intercepted instructions that could be monitored, a filter that selects certain of the elements based on an implemented monitoring policy, and a modifier that modifies the selected elements in accordance with the implemented monitoring policy. Monitoring policies can be directed towards performing runtime analysis and debugging of the intercepted instructions, towards improving the performance, on the client, of the intercepted instructions, or towards performing usability evaluations of the overall software which includes the intercepted instructions. In one embodiment, a monitoring policy can time one or more elements of the intercepted instructions so as to determine if any elements are taking too long to execute on the client computing device. In another embodiment, a monitoring policy can mark all of the elements of the intercepted instructions that either create objects or close objects on the client computing device and the monitoring policy can then search for memory leaks. In a further embodiment, a monitoring policy can mark some or all of the elements of the intercepted instructions that present choices to a user so as to monitor the user's selections and behavior.

p-0008The modifying component can be implemented on a separate server computing device from the server hosting the computer-executable instructions being provided to the client computing device, or it can be implemented on the hosting server or even the client computing device. If implemented on a separate server computing device, the hosting server can redirect communications to the server implementing the modifying component, thereby enabling the modifying component to act as a proxy for the hosting of the instructions. Alternatively, if implemented on the hosting server computing device, the modifying component can interface with the hosting software enabling communications with the client computing device. If implemented on the client computing device, the modifying component can act as a plug-in to the software hosting the instructions being downloaded, or it can act as a local proxy.

p-0009In a still further embodiment, the modifications can be done in advance such that multiple, differently modified versions of an application can be stored at the modifying component. The modifying component can then dynamically choose which version to provide to a client computing device. Alternatively, rather than performing the modifications in advance, the modifying component can, as it modifies an application, cache the modified application so as to respond more efficiently to subsequent requests. When subsequent requests are received, the modifying component can then choose to respond with a cached version, or it can generate, and, optionally, add to the cache, a new, differently modified version of the application.

p-0010This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

p-0011Additional features and advantages will be made apparent from the following detailed description that proceeds with reference to the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

p-0012The following detailed description may be best understood when taken in conjunction with the accompanying drawings, of which:

p-0013<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of an exemplary system that provides context for the described functionality;

p-0014<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary computing device;

p-0015<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of an exemplary system illustrating modification of software provided in real-time;

p-0016<figref idrefs="DRAWINGS">FIG. 4</figref> comprises two block diagrams of alternative exemplary systems, both illustrating modification of software provided in real-time;

p-0017<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram of an exemplary instruction modification component;

p-0018<figref idrefs="DRAWINGS">FIG. 6</figref> is a communicational flow diagram of exemplary modifications of software provided in real-time to multiple recipients;

p-0019<figref idrefs="DRAWINGS">FIG. 7</figref> is a communicational flow diagram of another form of exemplary modifications of software provided in real-time to multiple recipients;

p-0020<figref idrefs="DRAWINGS">FIG. 8</figref> is an exemplary instruction modification flow diagram;

p-0021<figref idrefs="DRAWINGS">FIG. 9</figref> is an exemplary iterative instruction modification flow diagram; and

p-0022<figref idrefs="DRAWINGS">FIG. 10</figref> is an exemplary instruction modification in parallel flow diagram.

DETAILED DESCRIPTION

p-0023The following description relates to the modification of computer-executable instructions representing some or all of a program that is delivered to a user over a network connection each time the user initiates the program. An instruction modification component can reside on the user's computing device, the server computing device hosting the program, or on an intermediate proxy device. A request for the computer-executable instructions from the user's computing device can be directed to the modification component, which, upon receiving such a request, can intercept the delivery of the instructions from the server and can modify the instructions in accordance with one or more instrumentation policies. An instrumentation policy can comprise instruction modifications directed to runtime analysis and debugging, modifications directed to improvements in performance, and modifications directed to user monitoring and improvement of the user experience. The instruction modifications of an instrument policy need not be directed to a single intercepted set of computer-executable instructions, and can, instead, be spread out across multiple instances of the computer-executable instructions being delivered to multiple users, or can even be adaptive in nature, such that the results of an initial set of modifications are used to tailor subsequent modifications of the same computer-executable instructions.

p-0024The techniques described herein focus on, but are not limited to, the modification of script-based computer-executable instructions delivered within the context of an environment based on the World Wide Web. In particular, modern web browsers are capable of acting as a host for the execution of scripts received from a server computing device in conjunction with one or more web pages being hosted by the server, or an associated server. The scripts are often designed to interact with one or more collections of computer-executable instructions executing on the server computing device and, in such a manner, perform useful tasks on behalf of the user. Because they work together in concert, the combination of the script-based executable instructions delivered to, and hosted by the web browser, and the computer-executable instructions executing on the server computing device is thought of as a single application, and is commonly known as a web-based application. However, while the descriptions below make reference to web-based environment, and illustrate exemplary instruction modifications with reference to script-based instructions within the context of a web application, the teachings below are not intended to be so limited. Indeed, as will be known to those skilled in the art, the mechanisms described below do not depend on, or require, any element unique to web applications, or the WWW in general, and, as such, are equally applicable to any computer-executable instructions delivered from one computing device to another on an as-needed basis. Such environments can include cluster computing, grid, data center or enterprise computing environments with the appropriate software deployment or software update systems in place.

p-0025Turning to <figref idrefs="DRAWINGS">FIG. 1</figref>, an exemplary network system <b>99</b> is illustrated comprising the network <b>90</b> itself, personal computing devices <b>10</b> and <b>20</b>, server computing devices <b>30</b> and <b>40</b>, and a storage device <b>50</b> associated with the server computing device <b>30</b>. Each of the personal computing devices <b>10</b> and <b>20</b> can be executing a web browser <b>11</b> and <b>21</b>, respectively. In addition, the server computing device <b>30</b> can be hosting a website <b>31</b>. As will be known by those skilled in the art, the website <b>31</b> can comprise, not only the communicational software necessary to receive, and respond to, requests from web browsers, such as web browsers <b>11</b> and <b>21</b>, but also comprises the one or more related individual web pages, and their associated content, such as embedded images and the like.

p-0026The website <b>31</b> can comprise one or more web pages that reference scripts, such as those contained in the script file <b>63</b> that is stored on the storage device <b>50</b>. As will also be known by those skilled in the art, the scripts of the script file <b>63</b> can be provided to a requesting web browser as part of the web page that referenced those scripts. Thus, as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the web browser <b>21</b> can have requested a web page of the web site <b>31</b> that incorporated the script file <b>63</b> and, as a result, the script file <b>63</b> can be provided to the web browser <b>21</b>. Upon receipt of the script file <b>63</b>, the web browser <b>21</b> can interpret and execute the scripts contained therein, and the execution of those scripts can generate a client application <b>62</b>. The client application <b>62</b>, representing the running form of the scripts of the script file <b>63</b>, can interact with a server application <b>61</b> and, together, the combination of the client application <b>62</b> and the server application <b>61</b> can be considered a single network application, or program, that provides utility to the user of the personal computing device <b>20</b>.

p-0027Although not required, the descriptions below will be in the general context of computer-executable instructions, such as program modules, being executed by one or more computing devices. More specifically, the descriptions will reference acts and symbolic representations of operations that are performed by one or more computing devices or peripherals, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by a processing unit of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in memory, which reconfigures or otherwise alters the operation of the computing device or peripherals in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations that have particular properties defined by the format of the data.

p-0028Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the computing devices need not be limited to conventional personal computers, and include other computing configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Similarly, the computing devices need not be limited to a stand-alone computing device, as the mechanisms may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

p-0029With reference to <figref idrefs="DRAWINGS">FIG. 2</figref>, an exemplary computing device <b>100</b> is illustrated. The computing device <b>100</b> can represent any of the computing devices <b>10</b>, <b>20</b>, <b>30</b> or <b>40</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>. The exemplary computing device <b>100</b> can include, but is not limited to, one or more central processing units (CPUs) <b>120</b>, a system memory <b>130</b>, and a system bus <b>121</b> that couples various system components including the system memory to the processing unit <b>120</b>. The system bus <b>121</b> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

p-0030The computing device <b>100</b> also typically includes computer readable media, which can include any available media that can be accessed by computing device <b>100</b> and includes both volatile and nonvolatile media and removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing device <b>100</b>. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

p-0031The system memory <b>130</b> includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) <b>131</b> and random access memory (RAM) <b>132</b>. A basic input/output system <b>133</b> (BIOS), containing the basic routines that help to transfer information between elements within computing device <b>100</b>, such as during start-up, is typically stored in ROM <b>131</b>. RAM <b>132</b> typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit <b>120</b>. By way of example, and not limitation, <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an operating system <b>134</b>, other program modules <b>135</b>, and program data <b>136</b>.

p-0032The computing device <b>100</b> may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a hard disk drive <b>141</b> that reads from or writes to non-removable, nonvolatile magnetic media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used with the exemplary computing device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive <b>141</b> is typically connected to the system bus <b>121</b> through a non-removable memory interface such as interface <b>140</b>.

p-0033The drives and their associated computer storage media discussed above and illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, provide storage of computer readable instructions, data structures, program modules and other data for the computing device <b>100</b>. In <figref idrefs="DRAWINGS">FIG. 2</figref>, for example, hard disk drive <b>141</b> is illustrated as storing an operating system <b>144</b>, other program modules <b>145</b>, and program data <b>146</b>. Note that these components can either be the same as or different from operating system <b>134</b>, other program modules <b>135</b> and program data <b>136</b>. Operating system <b>144</b>, other program modules <b>145</b> and program data <b>146</b> are given different numbers here to illustrate that, at a minimum, they are different copies.

p-0034Of relevance to the descriptions below, the computing device <b>100</b> may operate in a networked environment using logical connections to one or more remote computers. For simplicity of illustration, the computing device <b>100</b> is shown in <figref idrefs="DRAWINGS">FIG. 2</figref> to be connected to a network <b>90</b> that is not limited to any particular network or networking protocols. The logical connection depicted in <figref idrefs="DRAWINGS">FIG. 2</figref> is a general network connection <b>171</b> that can be a local area network (LAN), a wide area network (WAN) or other network. The computing device <b>100</b> is connected to the general network connection <b>171</b> through a network interface or adapter <b>170</b> which is, in turn, connected to the system bus <b>121</b>. In a networked environment, program modules depicted relative to the computing device <b>100</b>, or portions or peripherals thereof, may be stored in the memory of one or more other computing devices that are communicatively coupled to the computing device <b>100</b> through the general network connection <b>171</b>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computing devices may be used.

p-0035As shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, the network connection <b>171</b> can enable the computing device <b>100</b> to obtain program modules from one or more other computing devices in a real-time manner. Thus, for example, each time the program modules are to be executed and loaded into RAM <b>132</b>, they can be obtained anew from a remote computing device via network connection <b>171</b>. Alternatively, the program modules, after being obtained from a remote computing device via network connection <b>171</b>, can be retained in a local cache on the hard disk drive <b>141</b> for a short, predetermined amount of time, and can subsequently be loaded into RAM <b>132</b> from the local cache. Returning to <figref idrefs="DRAWINGS">FIG. 1</figref>, if the user of the computing device <b>20</b> were to quit the client application <b>62</b> and browse, with the web browser <b>21</b>, to another website, and then subsequently return to the website <b>31</b> and seek to use the program comprising the client application <b>62</b> and the server application <b>61</b>, the website <b>31</b> could again transmit the script file <b>63</b> to the web browser <b>21</b> so as to enable the web browser <b>21</b> to generate the client application <b>62</b>. This real-time distribution of the program comprising the client application <b>62</b> and the server application <b>61</b> enables the developers of such a program to be able to provide immediate updates, as the user receives the latest version of the script file <b>63</b> each time they seek to use the program anew.

p-0036This real-time distribution can be leveraged to modify the scripts of the script file <b>63</b> in a continuous manner, and thereby monitor, debug, make more efficient and otherwise improve the user's experience. Turning to <figref idrefs="DRAWINGS">FIG. 3</figref>, an exemplary network system <b>200</b> is shown comprising the personal computing devices <b>10</b> and <b>20</b>, the server computing devices <b>30</b> and <b>40</b>, and the storage device <b>50</b> from <figref idrefs="DRAWINGS">FIG. 1</figref>. However, the exemplary network system <b>200</b> further includes a script modifier <b>210</b> executing on a server computing device <b>40</b>. The script modifier <b>210</b> can intercept the delivery of the script file <b>63</b> from the server computing device <b>30</b> to the web browser <b>21</b> executing on the client computing device <b>20</b>, and can modify the scripts of the script file <b>63</b> before itself sending the modified scripts to the web browser <b>21</b>.

p-0037In one embodiment, illustrated by the exemplary network system <b>200</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>, the script modifier <b>210</b> can be hosted by, and can execute on, a server computing device <b>40</b> that is separate and apart from the server computing device <b>30</b> hosting the script file <b>63</b>. For example, the computing devices <b>30</b> and <b>40</b> can be configured such that server computing device <b>40</b> acts as a proxy server for the server computing device <b>30</b>, thereby causing the personal computing device <b>20</b>, and specifically the web browser <b>21</b>, to communicate with the server computing device <b>40</b> when attempting to communicate with the server computing device <b>30</b>. The establishment of the server computing device <b>40</b> as a proxy server can be tailored to the development of the program comprising the client application <b>62</b> and the server application <b>61</b>. For example, when a new version of the script file <b>63</b> is made available to clients, the server computing device <b>40</b> can be used as a proxy for the server computing device <b>30</b>, enabling developers of the script file <b>63</b> the ability to troubleshoot the scripts by using the script modifier <b>210</b> in the manner described in detail below. Once the developers become comfortable with the performance of the script file <b>63</b>, they can modify the proxy settings, and thereby enable the server computing device <b>30</b> to communicate directly with the personal computing device <b>20</b>.

p-0038Utilizing the script modifier <b>210</b> through an independent server computing device <b>40</b> that can be used as a proxy server can enable third parties, independent of the developers of the script file <b>63</b>, to provide debugging, optimization and monitoring services to a wide range of script authors. However, such an arrangement does add additional communicational complexity between the server computing device <b>30</b> and the end user on the personal computing device <b>20</b>. Turning to <figref idrefs="DRAWINGS">FIG. 4</figref>, two additional exemplary network systems <b>300</b> and <b>350</b> are shown, illustrating alternative hosting of the script modifier <b>210</b>. As illustrated by the exemplary network system <b>300</b>, the script modifier <b>210</b> can reside on the same server computing device as the hosting website <b>21</b> and the script file <b>63</b> which will be modified. In such a case, the script modifier can be a module of the web server software that is part of the website <b>21</b>. In the case where the web server software is distributed across many server computing devices, the script modifier modules may coordinate their modifications with each other. Alternatively, as illustrated by the exemplary network system <b>350</b>, the script modifier <b>210</b> can reside on the same personal computing device as the web browser <b>21</b> hosting the scripts of the script file <b>63</b> which will be modified. While the script modifier <b>210</b> can act as a local proxy on the personal computing device <b>20</b>, it can also be configured as a plug-in, or other extension, to the web browser <b>21</b>.

p-0039The existence of the script modifier <b>210</b> need not require any changes to the web browser <b>21</b> or the website <b>31</b>, as the script modifier <b>210</b> can operate such that the website <b>31</b> is unaware of any interception of the script file <b>63</b>, and the web browser <b>21</b> is unaware that the scripts received are not the original scripts of the script file <b>63</b>. To further provide for transparent operation, the script modifier <b>210</b> can pass through remote procedure calls, responses and other data that may be communicated between the client application <b>62</b> and the server application <b>61</b>. However, additional downloads, by the web browser <b>21</b>, of scripts, such as those contained within the script file <b>63</b>, can likewise be intercepted by the script modifier <b>210</b>.

p-0040Turning to <figref idrefs="DRAWINGS">FIG. 5</figref>, the operational flow <b>400</b> illustrates the components of the script modifier <b>210</b> with reference to the script file <b>63</b>. As shown, the script file <b>63</b> can be received by a parser <b>410</b>, which can, initially, identify the script file <b>63</b> as comprising scripts which can be modified by the script modifier <b>210</b>. Subsequently, the parser <b>410</b> can identify instrumentation points within the scripts of the script file <b>63</b>. In one embodiment, an “instrumentation point” can be any instance of a language element, such as a function declaration, statement, variable reference or the program as a whole. The identification of instrumentation points enables the parser <b>410</b> to generate an abstract syntax tree representation of the scripts contained within the script file <b>63</b> received by the script modifier <b>210</b>. However, as indicated previously, while the descriptions are directed to script files, nothing in the descriptions relies on any aspect of any scripting language and, as such, the disclosures are equally applicable to binary files or other files not coded in a high-level language. In such cases, the parser can, instead of generating an abstract syntax tree representation, instead generate some other intermediate representation.

p-0041Returning to <figref idrefs="DRAWINGS">FIG. 5</figref>, the parser <b>410</b> provides the identified instrumentation points to the instrumentation point filter <b>420</b>, which can identify the relevant instrumentation points depending on the one or more particular instrumentation policies being applied to the script file <b>63</b>. For example, if the instrumentation policy being applied to the script file <b>63</b> was directed towards collecting information when an error occurred as part of the running of the client application <b>62</b>, then the instrumentation point filter <b>420</b> could filter out instrumentation points such as conditional branches and loops and instead retain only those instrumentation points, such as the instrumentation points that register error handlers, that are relevant to the instrumentation policy. Alternatively, if the instrumentation policy being applied to the script file <b>63</b> was directed towards the detection of infinite loops, then the instrumentation point filter <b>420</b> would filter out instrumentation points that registered error handlers, and would instead retain those instrumentation points that dealt with loops, such as “for” loops and “while” loops.

p-0042The script modifier <b>210</b> is not limited to implementing only a single instrumentation policy at any given time or with respect to any given script or script file. Instead, the script modifier <b>210</b> can apply multiple instrumentation policies simultaneously. Thus, returning to the above examples, if the script modifier <b>210</b> was simultaneously applying both the instrumentation policy that collected error information and the instrumentation policy that detected infinite loops, then the instrumentation point filter <b>420</b> would retain for subsequent modification by the rewriter <b>430</b>, both the instrumentation points directed to error handlers and the instrumentation points directed to loops.

p-0043Once the instrumentation point filter <b>420</b> has filtered out the instrumentation points identified by the parser <b>410</b> that are not relevant to the one or more instrumentation policies being applied by the script modifier <b>210</b> to the script file <b>63</b>, the remaining instrumentation points can be provided to the rewriter <b>430</b> as shown in <figref idrefs="DRAWINGS">FIG. 5</figref>. The rewriter <b>430</b> can add additional instructions, or modify existing instructions, in accordance with the one or more instrumentation policies being applied by the script modifier <b>210</b>. For example, if the script modifier <b>210</b> was implementing the instrumentation policy directed towards collecting further information regarding errors, then the instrumentation points which registered error handlers that were provided to the rewriter <b>430</b> by the instrumentation point filter <b>420</b> could be rewritten to include additional instructions that could collect relevant information, such as the value of the stack at the time of the error, and the particular instruction that caused the error, and store such information in a log. Thus, a modified script file <b>463</b> being output by the rewriter <b>430</b> could comprise instructions that registered an error handler and additional instructions that logged error-related information, such as stack values and faulting instructions. The modified script file <b>463</b> could then be provided to the browser <b>21</b> instead of the original script file <b>63</b>, thereby implementing the instrumentation policy.

p-0044Information collected by instructions added by the rewriter can be periodically returned through standard communication mechanisms supported by the web browser <b>21</b> or other hosting software on the personal computing device <b>20</b>. Such information can be received by a log collector <b>440</b>, as shown in <figref idrefs="DRAWINGS">FIG. 5</figref>. Thus, returning again to the above example of an instrumentation policy directed to collecting additional information when an error occurs, the additional information collected by the instructions added by the rewriter <b>430</b> can be periodically provided to the log collector <b>440</b> by the web browser <b>21</b>. In one embodiment, the rewriter <b>430</b> can, in addition to the inserted instructions described above, also insert appropriate instructions to provide for the uploading of logged information to the log collector <b>440</b> by the web browser <b>21</b>.

p-0045The instrumentation policy implemented by the script modifier <b>210</b> can be distributed across multiple downloads of the script file <b>63</b>, thereby dividing the overhead consumed by the added instructions across multiple users, and minimizing the impact on any one user. Turning to <figref idrefs="DRAWINGS">FIG. 6</figref>, an exemplary communicational flow <b>500</b> is shown, illustrating the division of an instrumentation policy across multiple downloads of the script file <b>63</b>. Initially, a web browser <b>11</b>, executing on the personal computing device <b>10</b> can make a request <b>510</b> for a web page, comprising references to the script file <b>63</b>, from the website <b>31</b>. Analogously, another web browser <b>21</b>, executing on the personal computing device <b>20</b>, can make an equivalent request <b>520</b>. If the script modifier <b>210</b> is being implemented on an independent server computing device <b>40</b>, as shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, then the website <b>31</b> can redirect the requests <b>510</b> and <b>520</b> to the server computing device <b>40</b>. As will be known by those skilled in the art, the redirection <b>530</b> can comprise multiple communications between the server computing devices <b>30</b> and <b>40</b>. However, for clarity, those communications are not shown in <figref idrefs="DRAWINGS">FIG. 6</figref>.

p-0046In responding to the requests <b>510</b> and <b>520</b>, the script modifier <b>210</b> can intercept the communication <b>540</b> of the script file <b>63</b> and can insert additional instructions in accordance with the instrumentation policy. The first request <b>510</b> can be responded to with a modified script file <b>550</b> comprising additional instructions for some of the relevant instrumentation points, as would have been determined by the instrumentation point filter <b>420</b>. The second request <b>520</b> can be responded to with a different modified script file <b>560</b> comprising additional instructions for others of the relevant instrumentation points. Thus, as shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, the modified script file <b>550</b> can be provided to the web browser <b>11</b> via communications <b>570</b>, while the modified script files <b>560</b> can be provided to the web browser <b>21</b> via communications <b>580</b>. Each of the web browsers <b>11</b> and <b>21</b> will, therefore, be taxed to host only a portion of the additional instructions called for by the instrumentation policy, since each of the modified script files <b>550</b> and <b>560</b> only comprised a portion of those instructions.

p-0047For example, an instrumentation policy that searches for circular references between memory objects created by scripts and browser-generated web page objects can insert code at each instrumentation point that includes an instruction to which a web page object identifier is returned and can also insert code at each instrumentation point that represents a closure by the script. The inserted code need not do anything more than mark each web page object and each closure and can, therefore, add very little overhead to the modified scripts. However, to search for circular references, the instrumentation policy can also specify the insertion of code that checks all field stores of script objects to determine if they attempt to close an object referencing a web page object. Such code can noticeably impact the execution efficiency of the scripts if it were all inserted into a single modified script file.

p-0048Instead, however, the instruction point filter <b>420</b> can filter out all but some of the instruction points to which such code is to be added with each successive processing of the script file <b>63</b>. Thus, the rewriter <b>430</b> would only be adding the searching code to a fraction of the relevant instruction points each time script file <b>63</b> was modified. If there were 10 instruction points that involved field stores, and therefore called for the addition of the checking code, the instruction point filter <b>420</b> could, when processing the script file <b>63</b> an initial time, pass along only five of those instruction points to the rewriter <b>430</b> to add in the checking code. Such modifications could result in the modified script file <b>550</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>. When the script file <b>63</b> was processed a subsequent time by the script modifier <b>210</b>, the instruction point filter <b>420</b> could filter out the five instruction points previously provided to the rewriter <b>430</b> and instead provide, to the rewriter, the instructions points involving field stores that were not previously passed along. The rewriter <b>430</b> would, then, add the checking code to these instruction points, generating a different modified script file <b>560</b> that can be provided to a different web browser <b>21</b>. Thus, each of the modified script files <b>550</b> and <b>560</b> comprise only half of the checking code called for by the instrumentation policy, thereby spreading the execution of such code across multiple computing devices, or multiple instances of running the web application on a single computing device.

p-0049The selection of which instrumentation points to filter out, when the added code is being spread across multiple modified script files, can be performed by the instrumentation point filter <b>420</b> based on a random selection such that, statistically each instrumentation point will be passed by the filter <b>420</b> through to the rewriter <b>430</b> an equal amount of times across a sufficiently large number of downloads of the script file <b>63</b>. In addition, specific instrumentation points can be marked such that they are no longer in the pool of available instrumentation points for the filter <b>420</b> to choose from and can, therefore, be filtered out each time. For example, the log collector <b>440</b> can receive information from the logs obtained from the execution of earlier modified script files that indicates that a particular instrumentation point has been adequately checked. Such an instrumentation can be marked so that, with each subsequent download of the script file <b>63</b>, the instruction point filter <b>420</b> filters that instruction point out each time, and only passes a selection of the remaining instruction points on to the rewriter <b>430</b>.

p-0050The feedback received from previously supplied modified scripts can be used to inform the modification of the same script when downloaded in the future. Turning to <figref idrefs="DRAWINGS">FIG. 7</figref>, an exemplary communicational flow diagram <b>600</b> is shown, illustrating the incorporation of previously collected results into the subsequent modification of the same script file <b>63</b>. In particular, a web browser <b>11</b> can request a web page from the website <b>31</b> that references the script file <b>63</b>, causing the script file to be modified by the script modifier <b>210</b>, generating modified script file <b>610</b>. Modified script file <b>610</b> can then be sent to the web browser <b>11</b> via communication <b>620</b>, as shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. Subsequently, based on the instructions inserted by the script modifier <b>210</b> into the modified script file <b>610</b>, the web browser <b>11</b> can be instruction to provide log entries from the added instructions to the log collector <b>440</b> via communication <b>630</b>. Such log entries can comprise information which can be communicated to the script modifier via communication <b>640</b> and can be used by the script modifier to adjust the instrumentation policy accordingly.

p-0051If another web browser <b>21</b> were, at a later point in time, to request a web page from the website <b>31</b> that also references the script file <b>63</b>, the script modifier <b>210</b> can generate a modified script file <b>650</b> reflecting an updated set of modifications, generated based on information received by the log collector <b>440</b> from prior modified script files <b>610</b>. The modified script <b>650</b> could then be provided to the web browser <b>21</b> via communication <b>660</b> as shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. The modified script file <b>650</b> could then, itself, provide log entries to the log collector <b>440</b> which could be used to further adjust the modifications performed by the script modifier <b>210</b>. In one embodiment, the modified script file <b>650</b> need not even be sent to a different browser <b>21</b> from the browser <b>11</b> that received the modified script file <b>610</b>. Instead, the modified script file <b>650</b> could be sent to the same browser <b>11</b> as the modified script file <b>610</b> when the browser <b>11</b> requested the script file <b>63</b> a subsequent time.

p-0052Adaptive modification of the script file <b>63</b> can enable detailed monitoring of specific aspects of the script file <b>63</b> without requiring a determination of those aspects in advance of the monitoring. For example, the instrumentation policy applied by the script modifier <b>210</b> can be directed towards the monitoring of the performance of the script file <b>63</b>. Initially, the instrumentation point filter <b>420</b> can filter out all of the identified instrumentation points except those associated with the beginning and the end of whole blocks of script or event handlers. The rewriter <b>430</b> can then insert timing commands to measure the length of time each block of script or event handler takes to execute. Such timing information can be stored in a log file by other commands likewise inserted by the rewriter <b>430</b>.

p-0053After such an initially modified script file has been executed by one or more browsers, the information received by the log collector <b>440</b> can identify blocks of script or event handlers whose execution time exceeded some predefined threshold. For a subsequent series of modifications to subsequent downloads of the script file <b>63</b>, the instrumentation point filter <b>420</b> can filter out all of the identified instrumentation points except those associated with the identified blocks of script or event handlers that were too slow. Thus, the instrumentation points that were previously passed to the rewriter <b>430</b> will now be filtered out by the instrumentation point filter <b>420</b> as the information collected by the log collector <b>440</b> indicated that they no longer needed to be monitored. Instead, of the instrumentation points associated with the slow blocks of script or event handlers, a greater number of them can be provided to the rewriter <b>430</b>, thereby enabling more specific timing of individual portions of the identified blocks of script and event handlers.

p-0054As with the initial round of modifications, the subsequent modifications directed to more precise timing of individual blocks of script or event handlers can likewise collect timing information in a log and forward it to the log collector <b>440</b>. This subsequent round of timing information can be used to further refine the individual instructions or other more specific elements of the script file <b>63</b> that are to be timed in a subsequent series of modifications. In such a manner, precise timing information can be obtained regarding specific segments that may not be performing properly without burdening the browser with the amount of timing instructions that would have been needed if an iterative approach was not used.

p-0055While the above described examples refer to a log collector <b>440</b> that is part of the same computing device as the script modifier <b>210</b>, no such co-location is required. For example, in one embodiment, a third party can operate a computing device, such as computing device <b>40</b>, with one or more script modifiers, such as script modifier <b>210</b>, and can, thereby, offer script modification services to script developers to enable those developers to test, debug and otherwise optimize their scripts. In such an embodiment, the log collector <b>440</b> can be resident on each of the individual server computing devices, such as server computing device <b>40</b>, that are within the control of the script developers that are using the third party's services. In such a manner, the developers can directly receive feedback regarding their scripts. In an alternative embodiment, multiple log collectors can be used for a single log file. For example, the third party could design the rewriter <b>430</b> to insert code that instructs a hosting web browser to provide logged information, not only to the server computing device of the developer, but also to the server computing device hosting the script modifier <b>210</b>, enabling the script modifier <b>210</b> to perform iterative modifications, such as those described above.

p-0056In an alternative embodiment, log files need not be provided to a log collector <b>440</b> merely because there is information present in the log file. Instead, the rewriter <b>430</b> can insert instructions that collect information that may be relevant or useful only if one or more specific events occur. For example, an instrumentation policy can be directed to the collection of relevant information in case one or more predetermined errors occurs. In such a case, the logged information can be provided to the log collector <b>440</b> only upon the occurrence of one or more of the predetermined errors, and the code inserted by the rewriter <b>430</b> can specify the occurrence of one or more of those errors as a precondition for uploading the logged information.

p-0057Turning to <figref idrefs="DRAWINGS">FIG. 8</figref>, a flow diagram <b>700</b> is shown, illustrating an exemplary operation of the script modifier <b>210</b> according to one embodiment. Initially, a request for a script is received at step <b>710</b>. As indicated previously, the request at step <b>710</b> can have initially been directed to a web server hosting web pages that reference script files, but can then have been redirected to a proxy server hosting the script modifier <b>210</b>. Alternatively, the request received at step <b>710</b> can have been originally directed to the script modifier <b>210</b>.

p-0058In either case, once the request is received at step <b>710</b>, the script modifier <b>210</b> can obtain the script at step <b>720</b> and identify an appropriate instrumentation policy at step <b>730</b>. As also indicated previously, more than one instrumentation policy may be applied to any given script and, as such, step <b>730</b> can identify more than one appropriate instrumentation policy. Subsequently, at step <b>740</b>, the parser <b>410</b> can parse the script file <b>63</b> into an abstract syntax tree and can, thereby, identify instrumentation points in the scripts of the script file.

p-0059At step <b>750</b>, the instrumentation point filter <b>420</b> can filter the relevant instrumentation points given the one or more instrumentation policies that are being used with the script file <b>63</b>. The filtered instrumentation points can then have instrumentation code added to them, or can otherwise be modified in accordance with the identified instrumentation policy at step <b>760</b>. For example, if the instrumentation policy is directed to the detection of infinite loops, then the instrumentation point filter <b>420</b> can, at step <b>750</b>, filter out all of the identified instrumentation points except those directed to loops, such as “for” loops or “while” loops, and, at step <b>760</b>, the rewriter <b>430</b> can insert, at each of the loop instrumentation points passed to it by the filter <b>420</b>, instrumentation code that records the number of iterations that the loop has executed and instrumentation code that can terminate the loop if it exceeds a threshold number of iterations. Similarly, if the instrumentation policy was directed to the detection of inefficient string concatenation, then, at step <b>750</b>, the instrumentation point filter <b>420</b> can filter out all of the identified instrumentation points other than those directed to string concatenation via possibly inefficient means, such as the use of the “+” operator and, at step <b>760</b>, the rewriter <b>430</b> can insert instrumentation code that monitors the depth of the concatenated string to determine if the concatenation, for example, via the “+” operator, resulted in concatenated string whose depth is greater than necessary.

p-0060Once the relevant instrumentation points have been filtered at step <b>750</b>, and once the instrumentation code has been inserted at step <b>760</b>, the instrumented script can be provided to the requester at step <b>770</b> and, in one embodiment, thereby, end the operation of the script modifier <b>210</b>. In an alternative embodiment, however, the operation of the script modifier <b>210</b> can be influenced by information received by prior modifications to the same script file modified in response to a prior request. Turning to <figref idrefs="DRAWINGS">FIG. 9</figref>, a flow diagram <b>800</b> illustrating the operation of the script modifier <b>210</b> according to an alternative embodiment is shown. The initial steps <b>810</b> through <b>860</b> mirror those described above with reference to steps <b>710</b> through <b>760</b>. In particular, at step <b>810</b>, a request for the script can be received by the script modifier <b>210</b>, at step <b>820</b> the script modifier can obtain the script, and at step <b>830</b> it can identify the appropriate instrumentation policy for the script, as described previously in more detail with respect to steps <b>710</b> through <b>730</b>. Similarly, as described above with respect to steps <b>740</b> through <b>760</b>, the parser <b>410</b> can parse the script to identify instrumentation points at step <b>840</b>, the instrumentation point filter <b>420</b> can filter the relevant instrumentation points at step <b>850</b>, and at step <b>860</b>, the rewriter <b>430</b> can insert instrumentation code in accordance with the identified instrumentation policy.

p-0061The instrumentation code inserted at step <b>860</b>, however, can differ from the instrumentation code inserted at step <b>760</b> in that the instrumentation code inserted at step <b>860</b> can log information that can adjust the instrumentation policy for subsequent modifications of the same script file. Thus, at step <b>870</b>, the instrumented script is provided in response to the request received at step <b>810</b>, and, at step <b>880</b>, the log collector <b>440</b> can obtain the data that was logged by the instrumentation code inserted at step <b>860</b>. Using the received log data, the script modifier <b>210</b> can determine if additional investigation is required. For example, if the instrumentation policy was directed to identifying aspects of the instrumented scripts that were too slow, then the logged data received at step <b>880</b> could be timing information regarding whole script blocks and event handlers that was added at step <b>860</b>. The timing information can identify event handlers or script blocks that appear to be too slow and, therefore, require additional investigation. If such additional investigation is required, as determined at step <b>885</b>, then, at step <b>890</b>, new instrumentation points can be identified that are associated with the additional investigation. For example, if a script block was identified as being too slow, then the instrumentation points associated with additional investigations identified at step <b>890</b> can be instrumentation points representing sub-components of the script block that was determined to be too slow. Those sub-components can then have timing code inserted in an analogous manner to the timing code that would have been inserted around the script blocks and event handlers at step <b>860</b>. Such instrumentation code can be inserted at step <b>895</b> and the processing can then return to step <b>870</b> to provide the newly instrumented script to the requesting web browser. The iterative process would, thereby, repeat until, after obtaining logged data at step <b>880</b>, it was determined, at step <b>885</b>, that no further investigation was required, causing the processing to end at step <b>899</b>, as shown.

p-0062In another embodiment, the script modifier <b>210</b> can operate in an iterative mode of operation that varies slightly from the one described above. Specifically, while the modifications applied to any given script can be informed by the data collected by prior modifications to the same script, as described above, the script modifier <b>210</b> can further distribute the modification across multiple modified scripts such that any one modified script comprises only a fraction of the modifications called for by the instrumentation policy.

p-0063Such an alternative iterative mode of operation is illustrated in <figref idrefs="DRAWINGS">FIG. 10</figref>, showing the flow diagram <b>900</b>. The initial steps <b>910</b> through <b>940</b> can be analogous to the initial steps <b>810</b> through <b>840</b> and <b>710</b> through <b>740</b>, respectively, already described in detail above. At step <b>910</b>, the script modifier <b>210</b> can receive a request for a script file, at step <b>920</b>, it can obtain the script file, at step <b>930</b> the appropriate instrumentation policy can be identified, and, at step <b>940</b>, the parser <b>410</b> can parse the script file to identify instrumentation points. The instrumentation policy, however, can require the insertion of instrumentation code that can add a noticeable amount of overhead to the processing of the script files by the hosting browser. Consequently, the instrumentation point filter <b>420</b> can, at step <b>965</b>, select from among the instrumentation points relevant for the applicable instrumentation policy, thereby distributing the instrumentation code across multiple modified script files, and avoiding overloading any one browser's processing of the modified script file.

p-0064Prior to selecting from among the relevant instrumentation points at step <b>965</b>, the instrumentation point filter <b>420</b> can first, at step <b>950</b>, filter the instrumentation points identified by the parser <b>410</b> at step <b>940</b> to retain only those instrumentation points that are relevant for the instrumentation policy being applied to the script file. Subsequently, at step <b>955</b>, the instrumentation point filter <b>420</b> can determine if any of the filtered instrumentation points are still relevant in view of information that may have been collected from instrumentation code inserted into previous modifications applied to the same script file. If, at step <b>960</b>, the instrumentation point filter <b>420</b> determines that relevant instrumentation points remain, then, at step <b>965</b>, as indicated, it can select from among the remaining instrumentation points and provide those to the rewriter <b>430</b>, which can, at step <b>968</b>, insert instrumentation code at the selected instrumentation points. The modified script can then be provided, at step <b>970</b>, in response to the request received at step <b>910</b>. Subsequently, at step <b>980</b>, information logged by the instrumentation code inserted at step <b>968</b> can be received by the log collector <b>440</b> and, at step <b>990</b>, the received information can be evaluated to determine if any of the instrumentation points previously determined to be relevant at step <b>950</b> have now been sufficiently examined and do not need to be examined further and are, therefore, no longer relevant. Once none of the instrumentation points remain relevant, the decision at step <b>960</b> can determine to end processing at step <b>999</b>.

p-0065For example, if the instrumentation policy identified at step <b>930</b> was directed to the detection of memory leaks, then one type of instrumentation point that would remain after the filtering of step <b>950</b> would be field store instructions that are to be checked to determine if they attempt to close an object referencing a web page object. The process of performing such a check can be computationally expensive and, consequently, of the instrumentation points that are to have such checking code added to them, only a sample of them can be selected at step <b>965</b> and passed to the rewriter <b>430</b> to insert the relevant code at step <b>968</b>. However, after a quantity of modified versions of the script file have been transmitted to requesting browsers, the logged data received at step <b>980</b> can indicate that some instrumentation points have been sufficiently checked and no longer require checking. In particular, once a field store instruction has been determined that it does not close a heap object cycle that involves web page objects, there is no longer a need to continue checking that instruction. Consequently, such instrumentation points can be determined, at step <b>990</b>, to no longer be relevant to the purposes of the instrumentation policy, and can be filtered out at step <b>955</b>. The random selection at step <b>965</b>, therefore, can be from among the remaining instrumentation points.

p-0066The division of instrumentation code, such as that illustrated by the flow diagram <b>900</b> of <figref idrefs="DRAWINGS">FIG. 10</figref>, can also be used to compare measurements across multiple executions of the modified script. For example, an instrumentation policy can be directed to the detection of performance differences between different types of browsers, operating systems, or other elements of the platform hosting the modified scripts. In such a case, the timing instructions inserted by the rewriter <b>430</b> can include commands for specifying the platform element when logging data. Subsequently, when the logs are received by the log collector <b>440</b>, the script modifier <b>210</b> can compare the results from various platforms to determine if there are any differences between them.

p-0067As can be seen from the above descriptions, computer-executable instructions that are delivered on a real-time basis can be modified during the delivery process to include instrumentation instructions that can collect information regarding the execution of the delivered instructions on the destination platform. The instrumentation instructions can be spread across multiple delivery instances, and can be based on feedback received from previously modified and delivered instructions. In view of the many possible variations of the subject matter described herein, we claim as our invention all such embodiments as may come within the scope of the following claims and equivalents thereto.