GB2563381A

GB2563381A - Method and apparatus for executing a scripting language

Info

Publication number: GB2563381A
Application number: GB1708974.9A
Authority: GB
Inventors: Ruellan Hervé; Bellessort Romain; Ouedraogo Naël
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-06-06
Filing date: 2017-06-06
Publication date: 2018-12-19
Also published as: GB201708974D0

Abstract

A client device comprises an execution environment for a first scripting language, e.g. JavaScript. The environment executes a program written in the first scripting language, selects 2.3 a portion of the program to be replaced, and transmits 2.5 the code to a server. The server translates the received JavaScript code into a second language, e.g. WebAssembly code, and sends the translated program code to the client device. The client runs the translated code in place of the original scripting language code during execution of the program. This allows a lightweight device with limited processing power to more efficiently execute JavaScript programs when browsing the web. The client device may gather statistics related to the execution of the program and use such statistics to decide which portions of the program should be sent to the server for optimisation. The server may send wrapper code to the device to convert relevant parameters.

Description

The present disclosure concerns a method, device and system for executing a scripting language included in a Web page. It concerns more particularly the execution of JavaScript on a lightweight device.

Web pages are content made available on a server connected to a data communication network such as Internet. A client device, typically any computing device that may be connected to the data communication network, may access a Web page available on a server by addressing a request to this server. The server responds to the request with data representing the Web page. On the client device, software known as a browser is in charge of the Web pages request and to the rendering of the received Web pages. On the server device, software known as a Web server is in charge of receiving the requests and to respond with the Web pages data. Communications between the browser and the Web server is typically made using the Hyper Text Transfer Protocol (HTTP).

Web pages are constituted by data information describing the content to be rendered by the browser on the client. The main format and the first historically, used in Web pages description is the Hyper Text Markup Language (HTML). HTML is a static description language allowing to mix different media data to be rendered typically text, images, audio etc ... At some point, in order to bring dynamism in the rendering process, a need for client side computation happened. To answer this need, HTML has been provided with the ability to encapsulate some part of scripting languages. The rendering process on the browser comprises the execution of these parts of scripting language to enhance the content of a Web page. Typically, some controls may be implemented in the Web page to bring interaction with the user. The rendering may also interact with local resources of the client running the browser and so on. Rapidly the main scripting language used in Web pages became JavaScript. But some other languages are also used, as VBScript for example.

JavaScript has been conceived as an interpreted language. Figure 1 illustrates the general scheme of interpretation of some JavaScript code. Given a program written in JavaScript, which is a high level program constituted of program instructions, the interpreter first parse some instructions of the program in a step 1.1. Next, in a step 1.2, the interpreter translates these parsed instructions into Bytecode. This Bytecode if close to actual processors instruction sets and may be executed very efficiently on the actual client processor by a virtual machine engine. Next, the Bytecode obtained in step 1.2 is executed using the virtual machine engine in a step 1.3. Possibly, the process can loop back to step 1.1 in order to interpret more instructions of the program.

Using an interpreter usually results in a slow execution of the program. This is due to the fact that executing a Bytecode instruction has a large overhead.

Compilers, in opposition to interpreters, generate object code that can be directly executed by the processor. This compilation step is realized for the whole program before its execution. Modern compilers use complex optimization techniques to generate highly optimize object code.

Modern scripting language engines introduced a kind of mix between interpretation and compilation called Just in Time (JiT) compilation. Such engine comprises at the first level an interpreter and one, or several, level of JiT compilers. In addition to the basic interpretation scheme described in relation to Figure 1, these engines accumulate statistics on code execution. Typically, they accumulate the number of execution of some part of the code and/or the execution time of the code. These statistics may be accumulated per instruction, or for a set of instructions, or based on language structures as loops or functions.

Based on these statistics, the engine decides to compile some part of the code. Typically, the most used part of the code or the part of the code that are responsible for the most part of the execution time will be optimized by the JiT compiler. This decision and the compilation take place dynamically during the execution of the code. JiT compilation aims at optimizing the trade-off between compilation time and execution time to get an overall best efficiency in executing the code. Advantageously, several levels of increasingly complex JiT compilers may be used to better optimize the most used, or more resources demanding, part of the code.

Interpreting scripting languages as JavaScript is not very efficient. For each JavaScript instruction, many verifications and processing are required. For example, evaluating the addition in the following code is not straightforward.

function f(a, b) { return a + b;

}

As JavaScript is an untyped language, the variables ‘a’ and ‘b’ can have any type. Therefore, to evaluate the addition, JavaScript needs to check the type of both variables to decide which function to call to realize the addition. If both ‘a’ and ‘b’ are integers, it is also necessary to retrieve their respective values from the JavaScript objects corresponding to these variables before executing the processor instruction adding two integers.

As seen on the previous example, a part of the overhead of JavaScript comes from its untyped nature. Compiling JavaScript source code without any further information doesn't improve the processing speed much. The resulting object code still must realize all the verifications and processing linked to the unknown types of the variables.

In a modern JavaScript engine, the interpreter monitors the bytecode it is executing. This monitoring has two main purposes. First, the interpreter counts the number of time each JavaScript statement is executed. This enable to learn which are the most used parts of the JavaScript code. Second, the interpreter memorizes the types of the different variables for each execution.

In the example above, each time the ‘f function is executed, the types of variables ‘a’ and ‘b’ are memorized.

Counting the number of executions of each statement allows the engine to decide when to optimize part of the JavaScript code. For example, the JavaScript engine of the WebKit browser, taken as an example, optimizes, meaning compiles, a function once it has been executed 6 times or one of its statements has been executed 100 times.

Memorizing the types of the variables enables the JiT compiler to generate type-optimized object code. In the example above, if the ‘f function is always called with two integers, the compiler replaces the general addition, with all the type verifications, by the processor instruction for adding two integers. Usually, the compiler will also introduce some guards which are instructions for checking that the types of the variables are those expected. If any of those guards detects an unexpected type, the bytecode version of the function is used instead of the compiled one.

If several level of JiT compilers are included in a JavaScript engine, the JavaScript code is usually first interpreted, then compiled with the simplest JiT level, then possibly recompiled with more optimizations with a more efficient JiT level. A simpler JiT compiler generates object code faster, but the resulting object code is less efficient. A more complex JiT compiler will take more time to generate the object code, but the resulting code will be more efficient. Usually, code compiled with the simpler JiT compilers continues to be monitored during the code execution for gathering more information about the code. This information is used by the more complex JiT compilers to better optimize the code.

Other software languages may be used client side in the browser, “asm.js” is an experiment from Mozilla to include efficient code inside a browser, while remaining compatible with JavaScript, “asm.js” code is a subset of JavaScript where all the variables are annotated to define their types. These annotations use specific features of the JavaScript syntax.

For example, the previous example could be written as follows in “asm.js” to indicate that both variables are integer:

function f(a, b) { a = a|0;

b = b|0;

return (a + b)|0;

} “asm.js” has a memory model different from JavaScript, using a heap. This memory model is much closer to languages like C or C++ and doesn't require using a garbage collector, “asm.js” is not intended to be written directly by a developer, but rather to be generated by tools from typed languages such as C or C++.

Another client side language has been introduced for very efficient execution with the browser. This language is called “WebAssembly”. It is a new work for defining an assembly-like language targeted to the web. This language has no direct link with JavaScript. Its goal is similar to the goal of asm.js: providing very efficient code for Web applications.

The “WebAssembly” code is intended to be generated from C or C++ or other similar languages. “WebAssembly” is a generic assembly code and is platform independent. It is much lower level compared to JavaScript. Browsers can easily compile WebAssembly to highly optimized object code. While having a textual representation, “WebAssembly” implementations use a binary representation of the code, which is more compact and easier to parse for browsers.

Currently, there are two main ways for obtaining an efficient processing of the code contained in a Web application.

First, the developer can write JavaScript code and rely on the JavaScript engine to execute efficiently the code. This means that the JavaScript engine needs to include an efficient JiT compiler. This solution works well for most Web pages running on modern computers or even on modern high-end tablets or phones.

However, this option has limitations. The processing may be slow on any device not containing an efficient JiT compiler, or not having the resources for compiling quickly JavaScript code. A low-end phone or tablet may include an efficient JiT compiler. But it would have a slow processor, which would induce a slow execution of the JiT compiler. A constrained device may only contain a JavaScript interpreter, causing it to process the JavaScript slowly, all the more as its processor is not very powerful.

In addition, very demanding Web application may perform slowly. This is the case for example for high-end games.

The second option is for the developer to write part of the code in C, C++ or any other typed language. Then to use tools to generate “asm.js” or “WebAssembly” code, that is integrated in the Web application. Often only the most processing-intensive part of the code is developed in this way, the rest of the code being written in JavaScript.

This option enables to run the demanding code at a speed close to the one of native code. This has been used to run 3D game engines inside Web browsers. It could also be used for improving the processing speed inside lower-end devices without requiring the inclusion of an optimized JavaScript engine in them.

Using this option, a low-end device containing a JavaScript interpreter and a WebAssembly compiler could expect to run Web applications with a correct speed.

However, a drawback for this second option is that it requires more work from the developer of the Web application. Indeed, the developer has to identify the processing-intensive parts of its code, which is not always obvious, and write or rewrite them in a typed language.

This means that only part of the Web applications run by a low-end device would be optimized for it using some WebAssembly code. The remaining Web applications, using only JavaScript code, would be slow on this device.

The present invention aims at overcoming these drawbacks by providing a way for a low-end device to better run Web applications not optimized by their developers.

According to a first aspect of the invention there is provided a client device comprising an execution environment for a first scripting language, the execution environment being adapted for:

- executing a program written in said first scripting language;

- selecting a portion of code in the program;

- transmitting said portion of code or a reference to said portion of code to a server;

- receiving from the server a translated version of said portion of code written in a second language independent of the execution environment;

- executing the translated version of said portion of code in replacement of the portion of code written in the first scripting language during execution of the program.

In an embodiment, executing the translated version of said portion of code comprises:

- compiling the version of said portion of code written in the second language into a third language dependent on the execution environment; and

- executing the compiled version.

In an embodiment, the first scripting language is JavaScript.

In an embodiment, the execution environment is further adapted for:

- monitoring the execution of the program;

- accumulating statistics on the execution based on the monitoring; and wherein:

- the selection of a portion of code in the program is based on the accumulated statistics.

In an embodiment, accumulated statistics comprise at least one of:

- a number of execution of an instruction or a function;

- a number of execution of a loop;

- an execution time of a portion of code;

- a type of a variable used in a portion of code.

In an embodiment, said portion of code is a function.

In an embodiment, the second language is a generic assembly code, such as WebAssembly code.

In an embodiment, the execution environment is further adapted for:

- receiving from the server an indication that the portion of code is not to be translated.

In an embodiment, the execution environment is further adapted for:

- storing the accumulated statistics at the end of an execution of the program; and

- using the stored accumulated statistics during a further execution of the program.

In an embodiment, the execution environment is further adapted for:

- checking changes in the program before the further execution; and

- using the stored accumulated statistics during the further execution of the program if there are no changes.

In an embodiment, the execution environment is further adapted for:

- transmitting to the server related accumulated statistics along with the selected portion of code.

In an embodiment, the execution environment is further adapted for:

- receiving wrapper code along with the translated version of said portion of code for converting parameters.

In an embodiment, the execution environment is further adapted for:

- execute a guard code for checking the type of parameters before executing the translated portion of code; and

- execute the non-translated version of the portion of code written in the first scripting language instead of the translated one if the type of parameters doesn’t match the expected ones.

In an embodiment, the execution environment is further adapted for:

- compressing the portion of code to be transmitted.

In an embodiment, the execution environment is further adapted for:

- deferring the transmission of the selected portion of code and the reception of the translated version of the portion of code at the end of the execution of the program; and

- storing the received version of the translated version of the portion of code to be used in a further execution of the program.

According to another aspect of the invention there is provided a server device comprising an optimization environment, wherein the optimization environment is adapted for:

- receiving from a client device a portion of code written in a first scripting language;

- translating the received portion of code into a translated version of the portion of code written in a second language; and

- sending back the translated version of the portion of code.

In an embodiment, the optimization environment is further adapted for:

- storing the translated version of the portion of code; and

- sending back the stored translated version of the portion of code when receiving anew the same portion of code written in a first scripting language from a client device.

In an embodiment, the optimization environment is further adapted for:

- generating and sending back along with the translated version of the portion of code some wrapper code for converting parameters.

In an embodiment, the optimization environment is further adapted for:

- receiving related accumulated statistics along with the selected portion of code; and

- using these related accumulated statistics for translating the version of the portion of code written in a second language.

In an embodiment, the optimization environment is further adapted for:

- storing the received accumulated statistics; and

- using these stored accumulated statistics received from other client devices for translating the version of the portion of code written in a second language.

According to another aspect of the invention there is provided a method for executing code written in a first scripting language by an execution environment on a client device, the method comprising:

- executing a program written in said first scripting language;

- selecting a portion of code to be translated in the program;

- transmitting said portion of code or a reference on said portion of code to a server;

- receiving from the server a translated version of said portion of code written in a second language;

According to another aspect of the invention there is provided a method for optimizing code by an optimization environment on a server device, wherein method comprises:

receiving from a client device a portion of code written in a first scripting language;

- sending back the translated version of the portion of code.

According to another aspect of the invention there is provided a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to the invention, when loaded into and executed by the programmable apparatus.

According to another aspect of the invention there is provided a computer-readable storage medium storing instructions of a computer program for implementing a method according to the invention.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a circuit, module or system. Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, nontransitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 illustrates the general scheme of interpretation;

Figure 2 illustrates the client side algorithm in an embodiment of the invention;

Figure 3 illustrates the integration of the compiled portion of the code received from the server in an embodiment of the invention;

Figure 4 illustrates the process on the server in an embodiment of the invention;

Figure 5 is a schematic block diagram of a computing device for implementation of one or more embodiments of the invention.

Efficient execution of a scripting language on a client device relies on the capacity of the client device to implement a sophisticated interpreter, typically complemented by JiT compilers, in order to optimize the execution of the code. Lightweight client devices do not have the capacities to run efficiently sophisticated interpreters. According to one aspect of the invention, it is proposed to select during the execution of the code one or more portions to be optimized. Each portion is transmitted to a server to be translated into an optimized version written in a second language. Typically, this second language is low level and can be executed efficiently on the lightweight client device without necessitating a sophisticated compiler. In addition, the translated code is optimized. During execution, the client device executes the received optimized version instead of the original one. By deporting the burden of the optimization process on a server, the invention doesn’t require are large amount of processing on the client device.

Typically, the execution environment executing the program written in the scripting language on the client device monitors the execution and accumulates some statistics on the execution. These statistics are used to select a portion of the code to be optimized.

The accumulated statistics may be sent along with the portion of the code to help the server in the optimization.

An exemplary embodiment of the invention will now be described focusing on JavaScript as the scripting language. It should be noted that JavaScript is only an example and that the invention may apply to any scripting language.

Figure 2 illustrates the client side algorithm in an embodiment of the invention.

In the first step 2.1, the client monitors some JavaScript code while executing it. The execution of this JavaScript code can be linked to loading and displaying a Web page, to loading and executing a Web application, to loading and executing a local application, namely an application whose code is in JavaScript and that is stored locally on the client, to loading and executing a widget or an add-on, typically a small piece of code stored locally on the client and augmenting the functionality of another application of the client, or to any other usage of JavaScript code.

The monitoring of the code consists in accumulating statistics on the execution of the code. These statistics may comprise one of the following: a number of executions of an instruction or a function, the number of execution of a loop, the execution time of a portion of code, the type of variables used in a portion of code.

Preferably, this monitoring occurs while interpreting the JavaScript code. As an alternative, the client could have optimized the JavaScript code through a JiT compiler and monitor the execution of the optimized code.

As in a classic JavaScript engine, the client may count the number of execution of functions and of statements inside the function. Possibly, the counting can be limited to some of the statements inside the function. The goal of this counting is to detect code that is executed often. This includes functions that are called often. This also includes loops inside functions repeated many times. For achieving this goal, counting only function calls and loop repetition may be sufficient.

In addition of counting executions, the client may also keep execution information for the JavaScript code. This is also similar to what is done in a classic JavaScript engine. This execution information includes several aspects. Typically, variable types are monitored, to know whether a variable is an integer, a string, an object... Possibly, this can include the range of values for a variable. This is useful for example for integers to know which exact integer type is necessary: is a 16-bit integer sufficient, or is a 32-bit representation necessary.

Object structure may also be monitored. While JavaScript is an objectoriented language, it only provides a loose structure for the objects. This provides a good flexibility for the programmer, but makes it harder to optimize the code. Monitoring the structure of objects enable to create optimized storage for these objects that are faster to process. For example, instead of accessing an object variable from the variable name through a dictionary, the same variable could be accessed as an offset from a memory location.

In some embodiments, this monitoring is executed during a single session executing the JavaScript code. This means that the JavaScript code is loaded in memory, that its monitoring starts with its execution. Possibly the next steps of the algorithm are executed. Once the execution of the JavaScript code is finished, all the results of the monitoring are deleted.

In some other embodiments, this monitoring can span several sessions of running the JavaScript code. When the execution of the JavaScript code is finished, the result of the monitoring is saved and linked to the JavaScript code. If the JavaScript code is loaded from the Web, the result of the monitoring is typically stored in the Web cache as part of the JavaScript code entry in this cache. This means that the monitoring results can be split if the JavaScript code is split into several files. The JavaScript code and the monitoring results are stored even if the Web resource containing the JavaScript code is stale according to Web caching rules.

It is recalled that Web caches defines the notion of the freshness of a resource. This freshness indicates whether the resource may have changed or not on the server. A fresh resource is guaranteed not to have changed on the server. A stale resource may have changed on the server. A client must check with the server whether a new version is available or not when it has a stale resource in its cache.

If the JavaScript code is stored directly in the client, then the monitoring results are also stored inside the client, in some persistent memory, and linked to the JavaScript code. This can be realized, for example, through a specific database containing all the monitoring results for the JavaScript code contained in the client. Classic cache management methods can be used to limit the amount of memory used by these monitoring results. When starting the execution of some JavaScript code, the client looks whether it has stored some monitoring results for this code.

In the case of JavaScript code loaded from the Web, the client looks into its Web cache. If a JavaScript resource is stale and a new version is downloaded, the monitoring results are reused only if the JavaScript resource is unchanged. Several methods can be used to check whether a JavaScript resource is changed or not. In some embodiments, the old resource and the new one may be compared character by character, either directly, or using some kind of hash function on the code.

In some other embodiments, the resources may be filtered to remove non-significant differences before being compared. This filtering can for example remove comments, change all the spaces to some canonical form, change some JavaScript syntax to some canonical form... If using such kind of filtering, the monitoring results should be realigned with the new version of the JavaScript code. For example, if a function is moved two lines further due to the addition of some comments, the monitoring results corresponding to this function should be moved accordingly. This filtering could be implemented by comparing the bytecode for the old resource and the new one. Generating the bytecode removes all the non-significant differences between the two versions. In addition, the monitoring results can be linked directly to the bytecode of the new version if the two versions are determined similar.

In some embodiments, the comparison may be realized on a function per function level. The monitoring results are then kept for each unchanged function. However, this is much more complex as this requires a fine-grained comparison of the old resource and the new one for finding which functions are unchanged. In addition, even if a function is unchanged, its usage may be changed due to other parts of the code. For example, a previously unused function may be used a lot due to some added functionality in the code.

In the case of JavaScript code stored directly in the client, the client searches the database used for storing monitoring information. As for JavaScript code downloaded from the Web, the client must check that the code hasn't changed. However, instead of being realized at execution time, this check can be included in the client update procedure. When the client updates some JavaScript code, it then checks whether there is any stored monitoring information, and whether this information can be kept or not. As this process is not realized at execution time, it can take more time and therefore be more complex.

In a step 2.2, the algorithm determines if a criterion for optimization is met. Preferably, this step is integrated into the monitoring of JS code and is realized each time a monitored value changes. As an optimization, this step is realized only when a monitored value used by the test changes.

The criterion may be based on the number of execution of a function, on the number of execution of a statement, or on the number of execution of a loop, or on the execution time of the JavaScript code. As the duration required for obtaining an optimized version of a function is longer than in a classic JavaScript engine, the thresholds for deciding to optimize some code may be higher. For example, the thresholds can be of 10 executions of a function or 200 executions of a statement. The criterion may also be based on the number of execution of a loop, the execution time of a portion of code or the type of variables used in a portion of code.

If the monitoring spans several sessions of executing the JavaScript code, the tests may change to take these different sessions into account. For example, instead of using an absolute threshold on the number of executions, a relative threshold on the number of executions per session can be used. For example, the thresholds can be of 5 executions of the function per session or 100 executions of a statement per session.

When computing the average number of executions, some decay mechanism can be applied to give more importance to recent sessions. For example, the following formula could be used:

ασ_ν (1 — a)a_c a =----------1-------aw + 1 — a aw + 1 — a

Where:

• a is the number of execution per session;

• w is the sum of the weights of the previous sessions;

• σ_ρ is the weighed number of executions for the previous sessions;

• o_c is the number of executions for the current session;

• a is the decay parameter, with a value between 0 and 1, for example 0.9.

Upon updating the stored values of execution, the parameters σ_ρ and w are changed as follows:

w <- aw + 1 — a σ_ρ <- ασ_ρ + (1- a)a_c

The criterion may also be based on the type of the variables used in the portion of code. If these types correspond to types that cannot be easily represented in WebAssembly, then the portion of code will not be sent to the server.

If the test is negative, no optimization is realized, and the processing and monitoring of the JavaScript code continue at step 2.1.

If the test is positive, the algorithm continues at step 2.3. During this step, the JavaScript code to optimize is selected. The portion of code to be optimized may be any portion of code. In some embodiments, this code corresponds to a whole function.

Once the portion of code to be optimized is selected, some monitoring data gathered during the monitoring and associated to this portion of code may be retrieved in a step 2.4. As described above, this data may include variable types, object structure, and any kind of complementary information on the portion of code to be optimized.

Then, at step 2.5, the selected portion of code and eventually the associated monitoring data are sent to a server. If monitoring data are sent, it is necessary to link these monitoring data to the relevant parts of the JavaScript portion of code. This can be realized in several ways.

In some embodiments, a specific format can be used. For example, monitoring data may be encoded and may contain a link to the associated JavaScript code in the form of an offset in the JavaScript code.

In other embodiments, the language “asm.js” may be used to specify the types of variables. However, this is limited to integers and floats. Alternatively, another typed extension of JavaScript could be used, such as TypeScript. In this case, the JavaScript code is rewritten to include type information. Depending on the language used, this may also include information about object structure.

In a step 2.6, a response is received from the server. This response includes a compiled version of the portion of code in a second language. This compiled version is typically written in a lower level language than the scripting language to be able to be executed in a more efficient way than the sent portion of code. In the exemplary embodiment, this second language is a generic assembly code such as WebAssembly. If the sent portion of code is a function, the WebAssembly version corresponds to this function.

Possibly, some wrapper code in JavaScript may also be included in the server’s response. This may be necessary for converting the parameters sent from JavaScript into the input expected by the new WebAssembly code. As with a classic JavaScript JiT compiler, this wrapper code may also include some guards for checking the types of the input parameters of the WebAssembly code. Preferably those guards may also be generated by the client directly instead of being generated by the server and sent to the client.

This wrapper code may also contain a part of the portion of code sent to the server that the server has decided not to translate into WebAssembly.

In some embodiment, the server may decide that the optimization is not relevant. In this case, instead of the optimized version of the portion of code, the server sends back an indication that the portion of code is not to be optimized. The client device receiving such indication will use the original version of the portion of code written in the scripting language.

The server may decide that the optimization is not relevant, or that some part of the portion of code is not translated for several reasons. First, if there is not enough information about the variable types, the server will not be able to translate the original code into WebAssembly.

Second, if the type of a variable doesn’t correspond to something that is useful to translate or that can be translated into WebAssembly, then the server may decide not to do the translation. This can be the case, for example, for a variable that represents a JavaScript object.

Third, if the portion of code is too short, the overhead of calling the WebAssembly code may be too high and the server may decide not to do the translation. In the same way, the server may have an upper limit to the size of the portion of code it is willing to translate to preserve its resources.

At step 2.7, the WebAssembly code is compiled by the client. Depending on the available resources at the client, this compilation may include different levels of optimization.

In a step 2.8, the compiled WebAssembly code, as well as the JavaScript wrapper is any, are integrated into the JavaScript bytecode as a potential replacement of the original JavaScript code.

Figure 3 illustrates the integration of the compiled portion of the code received from the server in an embodiment of the invention. In this example, the portion of code is typically a function.

In step 3.1, a function for which an optimized version has been received from the server is called from some other code.

When calling the function, the code first executes a guard 3.2 that checks the type of the variables. This guard is typically generated by the client as the generation is not costly. Either the variable types are those expected by the compiled WebAssembly code, either they are different. According to this test, the control jumps to the non-optimized version of the JavaScript, namely the original one, in a step 3.3, when the types of the variables do not match the expected ones.

If the input parameters match those expected by the WebAssembly code, then the guards direct the execution flow towards the WebAssembly code. A first optional wrapper 3.4 is executed, typically to translate the function parameters into the format expected by the WebAssembly portion of code. Preferably this wrapper is generated by the server, as it knows the structure of the WebAssembly code input. Preferably this wrapper is some JavaScript code. This wrapper is translated into bytecode by the client. It could be compiled or optimized as it should be simple code with always the same structure. Possibly, this wrapper is created by the client using some indication returned by the server.

Next, the execution flow goes to the compiled WebAssembly code 3.5. Once the execution of the compiled WebAssembly code is finished, another optional wrapper 3.6 translates the result generated by the WebAssembly code to a suitable form for the calling JavaScript code.

Then, the execution goes back to the calling JavaScript code 3.7.

In the case the calling code is some WebAssembly code, a shortcut can be created to direct the execution flow directly from the calling WebAssembly code to the called WebAssembly code and back to the calling code. Possibly some lightweight wrapper may need to be inserted between the calling and called WebAssembly codes.

As an option, when receiving the compiled portion of code from the server at step 2.6 of Figure 2, the client can cache the received WebAssembly code, as well as the wrapper code if any. This cache is handled in the same way as the cache for monitoring data.

Figure 4 illustrates the process on the server in an embodiment of the invention.

In a first step 4.1, the server receives some JavaScript code, and possibly some associated monitoring data containing variable types, object structures and potentially other kind of information.

Next, in a step 4.2, the server compiles the JavaScript code, using the monitoring data, into some WebAssembly code. Preferably, this compilation includes some optimization steps, to increase the execution speed of the WebAssembly code, without impacting too much the size of the resulting code.

Next, in a step 4.3, the server generates, if needed, some JavaScript wrapper for converting the input parameters received from JavaScript to the expected parameters of the WebAssembly code.

For simple cases, such as calling a function taking integers as arguments, this code is easy to generate. For more complex cases, such as calling a function processing the content of an image, this code is more complex to generate and needs to be tailored according to the structure of the generated WebAssembly code. This step is optional, as this wrapper code could also be generated by the client.

Possibly, the server may include some indication enabling the client to generate this wrapper code.

Possibly, this wrapper code could include guards for checking the parameters received from the calling code. Preferably these guards are generated by the client.

Next, in a step 4.4, the server sends back to the client the generated WebAssembly code, as well as the wrapper code, if any.

In some embodiments, in order to minimize the bandwidth usage between the client and the server, the JavaScript code may be compressed using a generic compression algorithm such as DEFLATE.

As another option, a compact version of the JavaScript code is generated from the bytecode used by the client. This compact version removes all the comments, all the unnecessary spaces. It can also rename the variables to use shorter names.

As another option, a compact version of the JavaScript code is generated using a minifier tool. Such a tool removes all the comments, all the unnecessary spaces. It can also rename the variables to use shorter names.

In some embodiments, the server may not only use the monitoring data received from the client to generate the WebAssembly code, but also monitoring data received from other clients concerning the same JavaScript portion of code. This enables to use richer monitoring data, leading to better adapted WebAssembly code. It is to be noted that a JavaScript program embedded in a Web page is likely to be executed by numerous clients according to the invention. This makes this kind of optimization meaningful.

Possibly, the client can send some JavaScript code without any monitoring data. In this case, the server may use execution data received from other clients regarding the same portion of code to generate the WebAssembly code.

In some embodiments, the server may cache the generated WebAssembly code. This code can then be re-used for responding to requests from other clients regarding the same portion of code. For a better handling of the cache, clients should send the URL or some other identifier corresponding to the JavaScript code they send to the server. This enables the server to link the WebAssembly code to the associated URL or identifier. In addition, the WebAssembly code is also linked to the JavaScript code to which it correspond, as this JavaScript code can be a part of the code referred to by the URL or identifier.

In practice, the server can build a cache of WebAssembly code organized by URL (or any other identifier). Each URL is associated to a list of hashes corresponding to JavaScript snippets included in the code referred to by the URL. Each JavaScript snippet is associated to its monitoring data and to its corresponding WebAssembly code.

Possibly, several versions of WebAssembly code could be associated to a JavaScript snippet, corresponding to different monitoring data. For example, the addition function described in the previous example could have two WebAssembly versions, one for integers, another one for floating point values.

The delay between sending some JavaScript code to the server and receiving the WebAssembly version may in some case be too long to be useful in a single session using the JavaScript code. An alternative way of implementing the invention is to defer the steps from 2.3 to 2.6 of Figure 2, namely the selection of the portion of code to be optimized, obtaining the monitoring data, sending it to the server and receiving the optimized version from the server, at the end of a session. Once the session is ended, before removing the JavaScript code from memory, the step of checking the criterion for optimization, namely the step 2.2 of Figure 2, is realized for each portion of the JavaScript code for which monitoring information exists.

Then the following steps 2.3 to 2.6 are realized. Instead of compiling and executing the received WebAssembly code, the process stores the code in the cache. In this way, the WebAssembly code will be used in the next session using the JavaScript code.

In this alternative of the invention, step 2.2 may include a check on the freshness of the resource for JavaScript code contained in Web resources. Code contained in stale resource would not be translated into WebAssembly code as it could change before its next usage.

For code stored directly in the client, step 2.2 may also be executed during low activity periods of the client. For clients with intermittent connectivity to the server, step 2.2 may be run only when the connectivity to the server is available.

Using a remote server to compile some JavaScript code into some WebAssembly code means that the client trusts the server. In some embodiments, in order to improve the security, the client is configured to only use a server trusted by the user for compiling its JavaScript code.

In addition, the client may check the response of the server. While monitoring the execution of the JavaScript, the client also stores some input values for the code and the corresponding result. Upon receiving the WebAssembly code, before integrating it into its JavaScript code, the client tests it by using the stored input values and comparing the corresponding stored result with the result obtained from the WebAssembly code. This allows verifying that the WebAssembly code is correct for at least some values. This may help preventing a malicious server to corrupt the code and send back an optimized version of the portion of code with a different behaviour than the original portion of code.

In an alternative, the client includes some information about the options it supports regarding WebAssembly. For example, the client could indicate it supports SIMD instructions (for a future version of WebAssembly). In this case, the server would generate WebAssembly code which taking into account the indicated options.

According to this invention, a lightweight client is able to execute efficient JavaScript even if it is not able to run efficiently a sophisticated JavaScript engine. This feature significantly improves the execution of JavaScript on this kind of lightweight devices. The solution is cross-platform.

While the invention has been described with JavaScript and WebAssembly, it is applicable to optimize any scripting language having an execution scheme similar to the one of JavaScript. Any low level, efficient and cross-platform language similar to WebAssembly may be used to generate the optimized version of the selected portion of code.

Figure 5 is a schematic block diagram of a computing device 5.0 for implementation of one or more embodiments of the invention. The computing device 5.0 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 5.0 comprises a communication bus connected to:

- a central processing unit 5.1, such as a microprocessor, denoted CPU;

- a random access memory 5.2, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method for encoding or decoding at least part of an image according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example;

- a read only memory 5.3, denoted ROM, for storing computer programs for implementing embodiments of the invention;

- a network interface 5.4 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 5.4 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 5.1;

- a user interface 5.5 may be used for receiving inputs from a user or to display information to a user;

- a hard disk 5.6 denoted HD may be provided as a mass storage device;

- an I/O module 5.7 may be used for receiving/sending data from/to external devices such as a video source or display.

The executable code may be stored either in read only memory 5.3, on the hard disk 5.6 or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 5.4, in order to be stored in one of the storage means of the communication device 5.0, such as the hard disk 5.6, before being executed.

The central processing unit 5.1 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 5.1 is capable of executing instructions from main RAM memory 5.2 relating to a software application after those instructions have been loaded from the program ROM 5.3 or the hard-disc (HD) 5.6 for example. Such a software application, when executed by the CPU 5.1, causes the steps of the flowcharts shown in Figures 2 to 4 to be performed.

Any step of the algorithm shown in Figure 2 to 4 may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC (“Personal Computer”), a DSP (“Digital Signal Processor”) or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”).

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in 5 the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not 10 intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word “comprising” does not exclude other elements or 15 steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A client device comprising an execution environment for a first scripting language, the execution environment being adapted for:

- executing a program written in said first scripting language;

- selecting a portion of code in the program;

2. The client device according to claim 1, wherein executing the translated version of said portion of code comprises:

- executing the compiled version.

3. The client device according to claim 1 or 2, wherein the first scripting language is JavaScript.

4. The client device according to any one claim 1 to 3, wherein the execution environment is further adapted for:

- monitoring the execution of the program;

5. The client device according to claim 4, wherein accumulated statistics comprise at least one of:

- a number of execution of an instruction or a function;

- a number of execution of a loop;

- an execution time of a portion of code;

- a type of a variable used in a portion of code.

6. The client device according to any one of claim 1 to 5, wherein the second language is a generic assembly code.

7. The client device according to any one of claim 1 to 6, wherein the execution environment is further adapted for:

8. The client device according to claim 4, wherein the execution environment is further adapted for:

9. The client device according to claim 8, wherein the execution environment is further adapted for:

checking changes in the program before the further execution; and

10. The client device according to any one of claim 4 to 9, wherein the execution environment is further adapted for:

11. The client device according to any one of claim 1 to 10, wherein the execution environment is further adapted for:

12. The client device according to any one of claim 1 to 11, wherein the execution environment is further adapted for:

13. The client device according to any one of claim 1 to 12, wherein the execution environment is further adapted for:

- compressing the portion of code to be transmitted.

14. The client device according to any one of claim 1 to 13, wherein the execution environment is further adapted for:

15. A server device comprising an optimization environment, wherein the optimization environment is adapted for:

- sending back the translated version of the portion of code.

16. The server device according to claim 15, wherein the optimization environment is further adapted for:

- storing the translated version of the portion of code; and

17. The server device according to any one claim 15 to 16, wherein the optimization environment is further adapted for:

18. The server device according to any one claim 15 to 17, wherein the optimization environment is further adapted for:

- using these related accumulated statistics for translating the received portion of code into a translated version of the portion of code written in a second language.

19. The server device according to claim 18, wherein the optimization environment is further adapted for:

- storing the received accumulated statistics; and

- using these stored accumulated statistics received from other client devices for translating the received portion of code into a translated version of the portion of code written in a second language.

20. A method for executing code written in a first scripting language by an execution environment on a client device, the method comprising:

- executing a program written in said first scripting language;

- selecting a portion of code to be translated in the program;

21. A method for optimizing code by an optimization environment on a server device, wherein method comprises:

- sending back the translated version of the portion of code.

22. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 18 or 19, when loaded into and executed by the programmable apparatus.

23. A computer-readable storage medium storing instructions of a computer program for implementing a method according to any one of claims 18 or 19.