FR3087916A1 - CORRESPONDING SOURCE CODE PROCESSING METHOD, DEVICE, SYSTEM AND PROGRAM - Google Patents

Abstract

The invention relates to a method for executing a scripted code of an application, a method implemented by means of an electronic device, called a calling resource (ResA, A), within which said application is executable. According to the invention such a method comprises: - a step of obtaining (20) the scripted code of the application (PCP) comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least one function executable from a resource d 'destination execution (resX, B); a step of preparing a transmission data structure (PCP #, heap) of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each projectable object of the scripted code, at least one indexing data; a step of transmission (40), to a destination execution resource, of the transmission data structure (PCP #, heap) of the scripted code; and after the execution (50), by the destination execution resource, of at least one function of said at least one projectable object of the transmission data structure: a step of receiving (60) a data structure (ExObj, diff) of results of execution of said at least one function; a step of integrating the execution results of the execution results data structure within the calling resource.

Description

Method of processing a source code, device, system and corresponding program. 1.

Field The invention relates to the field of computer code processing.

The invention relates more particularly to the processing of codes called scripted.

This is code that can be interpreted and / or executed via a virtual machine or an interpreter.

More specifically still, the field of the invention is that of optimizing the execution of scripted code within a dynamic execution environment. 2.

PRIOR ART It is common, especially in an institutional or business setting, to have complex information system architectures, involving the implementation of numerous devices (computers, servers, mobile devices), interconnected by one or more networks. communications.

Within such organizations, the number of devices connected to each other continues to grow and the maintenance of these hardware and software architectures is expensive.

To try to save on these costs, companies also use so-called "cloud" services, for example in order to implement SaaS (for "Software as a Service") or AaaS type solutions. (English for "Application as a Service").

Although they can effectively limit the maintenance costs associated with own-owned architectures, these solutions are not exempt from other constraints (particularly in terms of data security or performance).

Regarding performance, whatever solution the organization chooses, it is often assessed against user expectations.

When the organization has its infrastructure, the need for performance, in particular for the execution of server or client-server applications, requires the purchase of ever more powerful equipment, with ever more resources (processors, amount of memory, fast discs), in order to meet the needs of users.

Now it turns out that although certain applications or certain programs are indeed able to make full use of the resources made available by the new hardware, others are often unable to do so.

Indeed, the programs and applications can be divided into two main categories (in what follows we only speak of programs).

The first is that of compiled programs; These are programs whose source code (for example written in the language C, C #, C ++, Pascal, etc.) is transformed, by the use of one or more compilers and / or one or more optimizers into one. executable code for a 2 given platform (a platform being understood as a processor architecture and / or an operating system).

These compiled programs are efficient in that they are able to take advantage of all the resources provided by the platform on which they run.

This efficiency derives from the numerous published works making it possible to optimize a binary code 5 as a function of the destination platforms (for example use of all the available processor cores, parallelization, common use of memory, etc.).

The second category is that of interpreted programs; these are programs whose source code is interpreted before being executed.

Popular programming languages of this type include, for example, PHP, JavaScript, or even Java bytecode.

In the context of the invention, the term scripted code is used to refer to the code of a program written in a language of this type.

The advantage of programs written in these languages is that they are cross-platform: the scripted code of the program runs the same on different types of platform.

Only the interpreter is optimized for a given platform.

This greatly facilitates the broadcasting of the programs.

On the other hand, the performance of this type of program is often poorer than that of binary programs, even when performing a dynamic compilation.

And for good reason, although much work has been carried out to improve the operation of interpreters and virtual machines, they have not always led to completely satisfactory results.

For example, the javascript language makes it possible to write programs (scripts) which are executed by a JavaScript engine (or JavaScript interpreter).

Such an engine is either integrated within a Web browser (Firefox ™, Chrome ™, Edge ™, Opéra ™) or implemented separately within a dedicated interpreter (for example Node.js' ").

As with other languages, javascript code has historically been a language that runs in a single-threaded environment (that is, all events occur one after the other).

When a long function 25 is implemented by the interpreter, the latter is not necessarily available to perform other tasks until the function is terminated.

Of course, with recent developments integrated into interpreters, it is possible to create isolated execution flows via available interfaces (for example “webworkers” in browsers) or in Node.js (webworkers, child.spawn / fork).

Thus, solutions theoretically exist for carrying out a remote function call within an execution flow different from the main flow.

However, the main problem lies in the scope of the code executed in another execution stream.

In fact, in order to be able to function correctly, these existing solutions, such as those mentioned above, must be integrated within the scripted source code when it is written by the developer.

For example, the call to a webworker must be planned in advance by the program developer who must therefore know, in advance of the phase, that the program is likely to run over a long period and that it is therefore necessary to provide one or more execution streams for the execution of the program.

Each flow of execution (each webworker) implements its own code (and defined by a particular javascript file).

There is therefore no dynamicity in the creation of a webworker and even less dynamic load distribution.

Furthermore, the execution streams are independent of each other.

This means that the latter do not make it possible to manage both the correspondence of objects between the caller and the called party because the existing solutions carry out recopies of objects (when they do), and neither do they make it possible to manage the extent of the applicability of variables and functions within the various execution streams.

There is therefore a need to provide a solution which does not pose the aforementioned problems and which makes it possible to take advantage of more resources available within the information processing infrastructures. 3.

Summary The method proposed by the inventors does not pose these problems of the prior art.

Indeed, there is proposed a method for executing a scripted code of an application, a method implemented by means of an electronic device, called calling resource (ResA, A), within which said application is executable.

According to the invention, such a method comprises: a step of obtaining (20) the scripted code of the application (PCP) comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least a function executable from a destination execution resource (resX, B); 25 - a step of preparing a transmission data structure (PCP #, heap) of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each projectable object scripted code, at least indexing data; a step of transmitting (40), to a destination execution resource, the structure 30 of transmission data (PCP #, heap) of the scripted code; and 4 after the execution (50), by the destination execution resource, of at least one function of said at least one projectable object of the transmission data structure: a reception step (60) of a data structure (ExObj, diff) of results of execution of said at least one function; a step of integrating the execution results of the execution results data structure within the calling resource.

Thus, the invention makes possible the execution, on multiple resources, of a scripted source code, without requiring, on the remote resources (destination execution resource), the implementation of a process other than that usually implemented for the execution of a code scripted by one of these destination execution resources.

According to one particular characteristic, the step of integrating the execution results of the execution results data structure within the calling resource comprises a differential check of the integrity of the updated data during the process. execution (50), by the destination execution resource.

Thus, it is possible, within the calling resource, to ensure that the remote execution results do not come into opposition with other resources (local or destination) which could have modified the same data before the receipt of this modified data by the destination execution resource.

This therefore avoids propagating or integrating inconsistencies in the data processed when the latter are at least partially processed remotely.

According to one particular characteristic, the step of obtaining the scripted code comprising a set of projectable objects comprises: a step of obtaining (10) a scripted source code (CSSE), representative of the application to be executed by the calling resource (ResA, A); a step of determining, within the scripted source code (CSSE), at least one function capable of being executed by a destination execution resource, called a projectable function; a step of modifying the scripted source code, delivering a scripted execution code 30 comprising said set of projectable objects, as a function of said at least one previously determined projectable function.

5 Thus, the scripted source code is not directly transmitted to the resources to be executed.

Instead, it is analyzed to determine which portions of code are likely to be projected to destination runtime resources, possibly by modifying the scripted source code itself.

5 According to a particular embodiment, in that the step of preparing a transmission data structure of at least one projectable object of said scripted code comprises a step of creating an indexing table (refA), for each projectable object (OA, XA) to be transmitted to a destination execution resource (ResX, B), array in which an index (0, 1, ...) is associated with an object reference (RefXA , RefXA, ...); 10 - a step of creating the transmission data structure (PCP, heap) in the form of an array comprising, for each projectable object, an index (0, 1, ...), corresponding to the index ( 0, 1, ...) of the reference of this projectable object within the indexing array (ref ,,), and a serialized representation (r0, r1, ...) of the projectable object; Thus, by using two different data structures, on the side of the calling resource, to index the scripted execution code which is transmitted, it is ensured that it is possible, when the code executed by the destination resource is finished, to find an object correspondence identical to that which was transmitted, and therefore a verification of the data received from the destination execution resource is allowed.

According to a particular embodiment, the step of receiving a data structure 20 of results (ExObj, diff) for executing said at least one function comprises: a step of receiving, of the transmission data structure (PCP #, heap) previously transmitted, in the form of an array comprising, for each projectable object, an index (0, 1, 2, ...), corresponding to the index (0, 1, 2, ... ) of the reference of this projectable object within an indexing array (refB) of the destination execution resource (ResX, B), and a serialized representation (r0, r1, r2 ...) of the projectable object; a reception step of the data structure of execution results (ExObj, diff) in the form of a table comprising, for each projectable object of the transmission data structure (PCP, heap) previously transmitted, an index (0, 1, 2, ...) and and a serialized representation (r'O, r'1, ...) of the modifications performed by said at least one function executed by the destination execution resource (ResX , B).

Thus, it is possible to follow the evolution (the modifications) carried out on the data, independently of the structure of the transmitted data, while keeping the indexing 6 carried out in input of the process during the creation of the data intended for the resource. destination execution.

According to one particular characteristic, the step of integrating the execution results of the execution results data structure (ExObj, diff) within the calling resource 5 comprises: an updating step, within the calling resource (ResA, A), of a list of objects, the update comprising the creation of a new object when an object absent from the transmission data structure has been created by the resource of destination execution during execution (50); 10 - a step of updating the values of the objects of the list of objects, comprising a check of the consistency of the values to be updated as a function of the original values contained in the transmission data structure.

Thus, it is possible to verify the preservation of the semantics, both on the code and on the data transmitted and returned by the destination execution resource.

According to one particular characteristic, the step of modifying the scripted source code, delivering a scripted execution code comprising said set of projectable objects, as a function of said at least one previously determined projectable function comprises: a step of determining at least one execution context of said application, as a function of the scripted source code (CSSE), said execution context of said application 20 comprising, for each variable and / or object of the scripted source code (CSSE), a representation of '' a corresponding variable and / or object, accessible and / or modifiable during projection to a destination execution resource, said execution context taking into account the scope of each variable and / or object of the scripted source code (CSSE ); a step of constructing the scripted code (PCP) as a function of the scripted source code (CSSE) 25 and of said previously determined execution context.

Thus, it is ensured that the code projected to the destination execution resource can be executed with a context identical to that of the local resource.

In the end, this makes it possible to ensure more efficient operation of the projected codes, while minimizing any possible execution invalidation operations.

It is understood, in the context of the description of the present technique according to the invention, that a step of transmitting information and / or a message from a first device to a second device corresponds at least partially, for this second device in a step 7 of receiving the information and / or the message transmitted, whether this reception and this transmission is direct or whether it is carried out by means of other transport devices, of gateway or intermediation, including the devices described herein according to the invention.

According to another aspect, the invention also relates to an electronic device 5 for executing a scripted code, called a calling resource.

Such a device comprises: means for obtaining the scripted code comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least one function executable from a destination execution resource; means for preparing a transmission data structure of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each object of the scripted code, at least one indexing datum; means for transmitting to a destination execution resource, the data structure for transmitting the scripted code; and means for receiving an execution results data structure, implemented after the execution, by the destination execution resource, of the transmission data structure; means for integrating the execution results of the execution results data structure.

The invention also relates, according to a complementary aspect, to a system 20 for executing a scripted code.

Such a system comprises at least one calling resource taking the form of an electronic execution device as described above and at least one remote resource, taking the form of a scripted code execution resource accessible from the calling resource.

According to a preferred implementation, the different steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of an execution device. according to the invention and being designed to control the execution of the various steps of the methods, implemented at the level of the communication terminal, of the electronic execution device and / or of the remote server, within the framework of a distribution of the processing operations to be performed and determined by scripted source codes.

8 Consequently, the invention is also aimed at programs, capable of being executed by a computer or by a data processor, these programs comprising instructions for controlling the execution of the steps of the methods as mentioned above.

A program can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any. other desirable shape.

The invention also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.

The information medium can be any entity or device capable of storing the program.

For example, the medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a mobile medium (memory card) or a hard drive or SSD.

On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.

The program according to the invention can in particular be downloaded from an Internet type network.

Alternatively, the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

According to one embodiment, the invention is implemented by means of software and / or hardware components.

From this perspective, the term “module” can correspond in this document as well to a software component, as to a hardware component or to a set of hardware and software components.

A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or of software capable of implementing a function or a set of functions, as described below for the module concerned.

Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is capable of accessing the material resources of this physical entity (memories , recording media, communication bus, electronic input / output cards, user interfaces, etc.).

In the same way, a hardware component corresponds to any element of a hardware set (or hardware) capable of implementing a function or a set of functions, according to what is described below for the module concerned.

It may be a programmable hardware component or with an integrated processor for running software, for example an integrated circuit, a smart card, a memory card, an electronic card for running a firmware. (firmware), etc.

Each component of the system described above obviously implements its own software modules.

The various embodiments mentioned above can be combined with one another for the implementation of the invention. 4.

Figures Other characteristics and advantages of the invention will emerge more clearly on reading the following description of a preferred embodiment, given by way of simple illustrative and non-limiting example, and the appended drawings, among which: FIG. 1 describes a system in which the invention is implemented; FIG. 2 describes a situation of loss of correspondence between objects for the remote execution of a scripted code; FIG. 3 describes a specific embodiment of the scripted code processing method; FIG. 4 illustrates the problem of the scope of the variables within a scripted code; FIG. 5 illustrates an architecture of a calling resource capable of implementing a processing method of the invention; FIG. 6 illustrates an architecture of a destination execution resource capable of implementing a processing method of the invention. 25 5.

Description 5.1.

Statement of Technical Principles As indicated above, an object of the invention is to allow efficient use of execution resources available within an infrastructure, within the framework of the execution of scripted programs by an interpreter or a virtual machine.

More particularly, the invention makes it possible to execute, remotely or locally, in a plurality of execution streams (an execution stream forming part of the group comprising a processor thread, a processor, a processor core, a scripted language thread, a context for executing a sequence of instructions), one or more portions of applications.

Thus, the invention allows dynamic integration of execution resources (servers, personal computers, smartphones and tablets) and dynamic allocation of portions of applications to newly integrated execution resources.

The invention provides a simple and effective solution to the problems mentioned above.

In particular, in the context of a single-server environment, the invention offers the possibility of automatically using all of the resources available within this server (by using all of the available processor cores).

The identification of the portions of code to be distributed is for its part either automatic or manual.

In the context of multiserver use, the invention makes it possible to distribute portions of executable code between several servers in order to use the execution resources available within these servers.

Thirdly, the invention also makes it possible to distribute portions of codes that can be executed on different devices (personal computers, tablets, smartphones) connected via one or more communication networks.

To do this, the invention is based on the implementation of a specific software module, which is used in supervised mode or in peer-to-peer mode.

In the embodiment described below, the supervised mode is detailed.

A general implementation of scripted code processing implementing the technique of the invention is described with reference to FIG. 1.

The specific software module (XStrmr), which runs on a calling resource (ResA), comprises a compilation unit (ComU) and an allocation unit (AllocU).

This software module (XStrmr): Takes (10) as input a scripted source code to be executed (CSSE); Analyzes (20) the scripted source code to be executed (CSSE) and searches for and / or constructs projectable portions of code (PCP) which can be projected to a destination execution resource (ResX ) (separate device or specific core of a multicore execution device); these first two steps are implemented by the compilation unit (ComU) Identifies (30) one or more execution resources (ResX) capable of executing the projectable portions of code (PCP); - when the code portions and the available resources are identified (and / or constructed), it projects (40) these projectable code portions (PCP), towards one or more execution resources (ResX) previously identified; The identified resources themselves implement a plurality of the functions described above, and therefore at least a portion of the software module (XStrmr) described, or even all of it; The execution resources (ResX) execute (50) the projected code portions (PCP); The results of execution (ExObj) of these code portions (PCP) by the available resources are transmitted (60) to the calling software module (XStrmr); The calling software module (XStrmr) processes (70) the received results.

These last five steps are implemented by the allocation unit (AllocU).

The execution streams are initialized before the transmission of the projectable code portions.

This means that when a portion of projectable code is transmitted, an execution flow capable of executing this projectable code has already been initialized.

Thus, in general, the calling resource is able to break down and / or modify (automatically or not) the original application, into independently executable portions (pieces), then is able to transmit these portions (and their execution context) to an identified resource, which executes this portion, using the transmitted context, and returns the result to the calling resource for processing.

More particularly, according to the invention, a method of managing execution streams is implemented in particular, a method which comprises a process for saving the portion of code (before its transmission to the destination resource) and a process for managing data. scopes (of variables in particular, also called scope management process) in order to ensure consistency in the execution of the code in the destination resource.

These two processes make it possible to certify that the portions of code executed by the remote resource preserve the semantics, both on the code and on the data (and therefore that they provide a result which is identical to that which would have been obtained if these portions had been executed by the calling resource).

More precisely, the method of managing execution flows is implemented, within the software module presented above, using the compilation units and the allocation units.

This method of managing execution flows makes it possible to keep, in the various flows created for the projection of portions of code, a unified execution repository, which is used to ensure uniqueness of the execution.

In other words, according to the invention, the execution of the various code portions projected in the parallelized execution streams is transparent for the application.

The latter does not know that it is the object of a decomposition into several portions executed independently by different resources, within different 12 execution streams: from his point of view, everything takes place as if the processing had been carried out within a single flow of execution.

This is advantageous in more than one way.

In particular, any application can be executed by the software module which is the subject of the present technique.

In particular, it is not necessary to write the application in a specific way.

A decomposition aid interface can be implemented later in order to guide the decompositions.

However, the developer is content to write the application as he wishes, according to his own requirements.

The software module analyzes the code of the application, as a function of specific analysis parameters and alone determines the portions of code (functions, procedure, modules) to be projected in parallel execution flows.

The developer does not have to learn an interface or develop in a specific way.

In other words, in order to 'parallelize' a program, when loading the program, the compilation unit identifies (and / or builds) potentially parallelizable functions and generates the necessary instrumentations so that they can be subjected to the allocation unit.

For the execution, the allocation unit is based on three functional blocks (these blocks potentially being able to be integrated within one and the same program): service, master and runner.

A runner materializes the waves.

The master's degree in the placement strategy of projectable functions.

The service provides the code to be executed in the cluster.

In order to execute a function on a destination execution resource: the service is in charge of the start and the end of the execution of the projectable functions.

For execution, it defines a job which contains the data necessary for the execution of the function (input parameter, execution scope, serialized object system, function code) in the form of a transport data structure and passes it to the master. 25 the master is in charge of placing the various jobs on the runners.

It manages a queue for waiting and executing projectable (transported) functions. a runner is used to run one or more jobs in parallel on a resource (for example a nodejs, or a browser, a server, a cluster, etc.). once the function has been executed, the ru nner performs differentiation work, adds the output parameters and communicates to the master the end of the execution of the job (the differentiation work is notably carried out using a structure of 13 differentiation data as explained below in connection with an embodiment). the master withdraws from the job execution queue and indicates to the service that it is finished; the service validates the ACID properties (unless they do not apply), the 5 order properties and updates the object space.

A specific embodiment of the proposed technique is described below in connection with the scripted language “javascript”.

It is understood that this embodiment in the context of the javascript language is presented by way of example and that it is in no way limiting of the technique in itself, which can generally be implemented. in any scripted or interpretable language, such as PHP, or even bytecode (java or other).

In general, according to the invention, the scripted code is cut / modified / structured, in one or more passes, by the compilation unit of the software module.

Once structured in portions of projectable code, the allocation unit of the software module decides, on the fly, of the execution of portions of code using other available resources.

Thus, beforehand, it is considered that the software module is able to obtain or detect one or more available resources, locally or remotely.

The way in which this detection is carried out does not form part of the object of the invention.

The only important characteristic being that a server (eg the local resource) has knowledge of the available resources.

On the basis of the code divided into projectable portions and of the plurality of available resources, the software module: identifies at least one destination execution resource; locally defines a data exchange structure, this exchange structure comprising at least a pointing list and a list of objects; serializes the exchange structure; 25 transmits the serialized exchange structure to the destination execution resource. - processes the results received from the destination execution resource, these results being included in the initial data exchange structure, retransmitted by the destination execution resource, and a differences structure, listing the modifications made .

It is noted that the operations defined above, in particular the operation of identifying the destination resource can be carried out upstream, just like the definition of the exchange data structure.

14 In other words, the above technique consists of a modification of the serialization, which no longer consists of transmitting the serialized objects as they are, but rather of transmitting a different data structure, resulting from the objects to be transmitted, this structure data is constructed by the calling resource, on the basis of the objects (and functions) to be projected, and then is itself transmitted to the destination execution resource.

The destination execution resource creates all the objects on the basis of this projected data structure and updates this projected structure (when the functions or objects modify attached values) and creates a complementary difference data structure, which takes stock of the data modified during the execution of the functions.

When the processing operations are finished, these two data structures (the original structure and the difference structure) are returned to the calling resource, which, on the basis of the modifications made, performs the updates of the objects (and the their data) to reflect the execution that took place within the destination execution resource (when certain properties are to be respected and are of course respected, for example the ACID properties, as described below).

The data structure is constructed, for example, by serialization.

Serialization makes it possible to build a machine-independent data structure transferable over a network protocol and after reception, to perform an instantiation in order to reconstruct the original data structure According to the present technique, the processing of decomposition, identification, creation, projection and The processing of the results is carried out iteratively and / or recursively throughout the execution of the application. 5.2.

Description of an Embodiment In this embodiment, the implementation of the technical principles previously described in javascript language is described.

More particularly, we describe the way in which one manages, for the JavaScript language, the execution contexts, the management of the scope, and the conservation of the ACID properties of the executed code. 5.2.1.

Execution support in different streams Javascript engines allow the creation of isolated execution streams via interfaces available in browsers (for example webworkers) or in Node.js (webworkers, child.spawn / fork).

The method described here makes it possible to perform a function call from an execution stream A in a second execution stream B, whether local (on the same computer) or remote (on another computer) while maintaining a unified execution context.

The method makes it possible to provide unified remote execution functionalities and opens the field of application of the remote execution to any function and without limitation. 5.2.1.1.

Correspondence of the object systems Basically, to allow a unified execution, it is necessary to have a solution 5 for monitoring the modifications carried out on the objects by the called function and to maintain the object systems of stream A and of stream B in correspondence. .

When a JavaScript flow A creates a flow B, the execution flows are isolated in the sense or, no property or objects of A are accessible by B.

The only way for A to communicate properties or objects to B is to use a means of communication between A and B (IPC).

The 10 data transmitted by A are thus copied into the space of B.

B can use them as he sees fit because there is no connection between the data of A and the data of B.

Conversely B can use an IPC to communicate properties or objects to A.

In order to transmit objects, they are serialized, then once received by the recipient execution stream, they are instantiated in this recipient stream.

In Figure 2, stream A wants to communicate to stream B the object Oa, containing the properties p1 (numeric 12) and p2 (a reference to an object Xa).

Xa containing a pl property (numeric 13).

Serialization (Sr) of object Oa is performed, as well as that of Xa (e.g. using the JSON.stringify (Oa) call).

Once received, the objects are instantiated (lnst) in Ob and Xb (eg using the eval or JSON.parse call).

20 It is interesting to note that this way of doing things, which can be used in Javascript, makes it possible to exchange objects, but it has the major and limiting disadvantage of losing the correspondence of the objects between the streams A and B.

For example, stream B does not know (has no knowledge of the fact) that Ob corresponds to Oa, and that Xb corresponds to Xa.

The technique implemented by the inventors creates the illusion that the function which performed in stream B performed in stream A.

Also it is possible to maintain an equivalence of the objects in order to be able to update the modifications of the objects within the real objects of stream A.

To do this, the inventors have defined a solution which extends serialization and instantiation in order to preserve these links.

This solution comprises several steps, illustrated in relation to FIG. 3.

The textual elements of Figure 3 do not constitute text, but code, and therefore do not require translation.

In figure 3, we present (on the left the state of the objects in the execution flow A.

Step 0 (S0) consists of an extension of the serialization: 16 For each object, an index (0a-> 0 and Xa-> 1) is assigned; A refA array records (saves) the object reference (ref

[0] = refOa and ref

[1] = refXa) Another heapA array records (saves) the content of each object, and if 5 it's another object the index of that object (heapA

[0] = {p1: {type: "number", value: 12}, p2: {type: "object", index: 1}} and heapA

[1] = {pl: {type: "number", value: 13}} So refA

[0] and heap '

[0] are associated with Oa and refA

[1] and heap '

[1] are associated with Xa.

During the communication (serialization) carried out between A and B, only heapA is transmitted.

In the figure, the heap table is shown only once for clarity in the presentation.

Step 1 (Si) corresponds to the step of instantiating objects within stream B.

On B: refB is empty (refB = []), then the received heapA (which therefore becomes heapB from the point of view of flow B) is scanned for all the elements.

For each element a new object is instantiated and the reference is stored in the corresponding index in ret.

Thus, after instantiation, the content of table refB of stream B makes it possible to make a correspondence with the content of refA of stream A (we know for example that refB

[1] on B denotes refA

[1] on A).

At this stage, the stream B is able to execute one or more functions present within the objects Ob or Xb.

These functions, for the example described here, read and / or modify the new 20 objects (Ob, Xb) and instantiated parameters.

For example, the flow B changes Ob.pl from the value 12 to the value 24 and associates with Ob.p2 a new object Yb.

In addition Xb.pl is modified from the value 13 to the value 243.

To do this, stream B uses the heap received from A.

Either A has deleted the heap on his side, or A has kept the heap on his side, depending on the operational conditions of implementation.

25 Step 2 (S2) calculates the differences (following the execution of the functions): Once the function (s) have been executed, it is possible to browse the array refA and to check using the heapB if a property d 'an object (Ob, Xb) has changed or not.

During this journey we thus create a diffa table which contains the list of differences.

In the event of a change to a new object, a new index is created in heapa in order to materialize the new object.

The diffa array thus contains for object 0 the new value for pl (ie 24) and the new index (2) of the object created in heapB for p2 (refYb).

It will also contain the new value of the pl property of Xb (ie 243).

17 Assuming that Ob contains another property (p3) and its value is unchanged, it will not be described in the diffa array.

The diffa array only contains the modifications on the objects (addition of an object, modification of an object (modification of a property, deletion or addition of a property).

5 After calculating the differences and updating heapB, diffa and heaps are transmitted to stream A (that is, it is serialized and transmitted to calling stream A).

We can also only transmit diffa and be content to keep heapa on the calling resource (i.e. we do not retransmit heapB at the same time as diffB at the end of the execution on stream B, we only retransmits diff .: this alleviates the transmissions, but this puts more memory pressure on the calling resource).

Step 3 (S3) instantiation of new objects on A: When receiving diffB, A (Step 3) instantiates all new objects inserted in heap ,,, and adds the references in the refA array.

The ACID properties of the objects can be verified at the end of this instantiation (see below); Step 4 (not shown) update the objects on A: Last step using the diff array, A updates the content of the objects in A.

As shown in the diagram, all the objects have been reconstructed between A and B and the modifications have been carried over to the model space of A.

20 Note that steps 0, 1, 2, 3 and 4 are executed respectively within streams A, B, B, A, and A and that during these steps nothing else can be executed within these waves.

Note also that if the object Xa is accessed by another object other than Oa, the new value of Xa has been propagated.

If Xa was only referenced by Oa, then after the update it will be collected by the virtual machine garbage collector. 25 5.2.1.2.

Effective Calls of Functions Thanks to the method described above, the inventors have the means of maintaining the equivalences of the object systems between two streams, which was not possible previously.

In order to perform the function call, all the input parameters of the function are serialized.

Then once executed, output parameters are added in the serialization, according to the same mechanism.

It is thus possible to call a function while maintaining the objects linked to the input and output parameters. 18 5.2.1.3.

Scope management Apart from the parameters, a function may need to access properties / objects accessible in its scope (in its scope), that is to say properties / objects, which although not being defined within an object to be transmitted to the destination execution resource, are all the same accessible in the initial scripted code.

This is for example the case with global variables, variables or properties of a previous level or even parent objects (when inheriting objects for example).

Thus, a problem to be solved in order to be able to perform a transfer to another stream is also to be able to perform an execution context transfer, the context comprising all the properties / objects to which the function has access during its execution.

The determination of this context is carried out upstream, that is to say before the transfer to the destination execution resource, normally by the compilation functional unit.

The created context is one of the objects which are serialized and transmitted by the transmission method previously described.

Figure 4 illustrates the problem of scopes (execution scopes).

It is understood that if it is desired to transmit, to a destination execution resource, the execution of f2 and f3, the correct transmission of the execution context is essential.

Notably, for example, the scope of f3 is different from the scope of f2, despite the fact that these two functions f2 and f3 define a variable named t whose scope is limited.

For example, the scopes of f2 and f3 must not collide.

Thus, in order to transmit the context of the environment to a remote function call, two possibilities for processing the scopes are possible: either to be in the execution phase in order to be able to access the environment and transmit it directly, or to rewrite the code scripted in a certain way.

A first solution consists in simulating the JavaScript context.

In this first solution, in order to transmit the context without the aid of the interpreter 25 (for example without the aid of the Javascript engine), it is necessary to create the context in the chosen language (for example in Javascript).

For this, it is necessary to know all the scopes of variables, strings of scopes and all accesses to the context.

To be able to do this, we must exclude any dynamic scope, ie the use of keywords like “with” and “eval”, and therefore be in a purely lexical scope.

The creation method includes: 30 - The construction of the scope chain associated with each scope in the program; 19 The separation of the program into two sets of scopes, one for the scope of functions that will be performed remotely (remote) and the other for the rest of the program (resident); Optionally, remove, in the resident scopes, all variable bindings that are not used in a remote function; Optionally, merge some scopes by renaming a conflicting link or variable name (for example, to keep only a single scope per function) Transform the program as follows: 10 When the global scope is created, create an empty object and place this object as the current context in the 'global' object (in the following, let's name it (global.currentContext) to be accessible to the whole program;; Each time a scope is created, generate an empty object, add it a 'parent' symbolic property that points to the context pointed to by `global.currentContext ', and 15 put this object as the current context in the' global 'object (global.currentContext).

Whenever a scope is destroyed, point the 'global.currentScope' to the object pointed to by `globa.currentScope.parent.

Thus, a dynamic stack of contexts whose top is pointed at any time by 'global.currentContext' is created and updated during the execution of the program; Whenever a function 'f' is defined: a. add a symbolic property f.context pointing to the current context pointed to by 'global.currentContext' (f is the function object); b. add in the context object pointed to by `global.currentContext all the 25 parameters of the function (the name of the parameter becoming the name of a property, and its value, the value of this property); ; Replace all access to a variable v included in a resident scope in a function f: a.

If step 4 (optional optimization) is applied, find the name of the link corresponding to the variable v (call it w); b.

If step 4 is not applied, w =; vs.

Replace access to variable v by access to f.context.w.

By using this first solution, consisting in rewriting the code and defining a transmission context which are associated with the different scopes, transmitting and executing a function to a destination execution resource is easy: it suffices to transmit the object function, which contains all the execution context of this function through its symbolic 5 'context' property.

A second solution is to capture the context and falsify it.

To be able to implement this solution, we must exclude any dynamic scope, ie the use of keywords “with” and “eval”, and therefore be in a purely lexical scope. 10 1.

Build the scope chain associated with each scope in the program.

Mark the binding with a constant attribute for variables declared with const and mark the binding with a tdz attribute (temporal dead zone) for variables declared with const or let and which may end up in a temporal dead zone.

For the latter, we can also fix the exact moment when the link is surely not in the temporal dead zone, but we will describe this later as an optimization. 2.

For each function, divide the program into two sets of scopes, one for the scope of the functions you want to perform remotely (remote) and one for the rest of the program (resident). 3.

Optimized and optionally, iterate through the code of the function we want to execute remotely to mark each binding that the function needs in the resident scope. 4.

For each function we want to perform remotely: a.

Add a function that captures the context in a context object with the variables coming from a link marked in step 3 (or all the variables of the resident scope if not in step 3). i.

Build a contextual object, with (I) an identifier defining the configuration of the Temporal Dead Zone variable, (II) a list of variable names in the Temporal Dead Zone, (III) two empty objects, one to contain the non-mutable variables (const), and another for mutable variables (var, let, function and class). ii.

Place one property by variable, the property name is the name of the variable and the location of the property depends on the type of the variable (one of the two objects defined as i.II: mutable or non-mutable).

The value of the property is the value of the variable. iii.

In order to manage the temporal dead zone, we must "try / catch" each access to the variables potentially in the Temporal Dead Zone in case 5 these variables are really in the Temporal Dead Zone.

In this case, we just need to insert the name of the variable into the Temporal Dead Zone (i.l) array.

We also need to calculate an identifier that identifies the configuration of the Temporal Dead Zone variables by setting a bit in the identifier representing that variable. 10 b.

Add a function which updates the context from the “context” object by writing the variables coming from a link marked in step 3 (or all the variables of the resident scope if not in step 3).

In the case of a variable potentially in the Temporal Dead Zone, we need to test if it was indeed in the Temporal Dead Zone of the context object, by testing the id bit, and 15 if not, update the context with the value from the context object. vs.

Link these two new functions in the function object using carefully named properties (like "captureContext" and "updateContext") or by using a symbol. 20 d.

One can imagine the addition of a third function using the first two functions, which performs the remote call with a specific mechanism (context capture, remote call with this context, context update). 5.

Replace the function in the remote part with a function that: a.

Takes a context object as an argument. 25 b.

Create all the necessary variables with their initial value contained in the context object.

If the variable is overall non-mutable, use const to declare it.

If the variable is in the mutable (read / write), use let. vs.

Execute (or call) the original code in a try block. d.

Create all the necessary variables in the Temporal Dead Zone with the let. 30 th.

Updates the context object with the value from the context in the finally block corresponding to the try block.

Simply ignore the variable in the temporal dead zone or in the r (read) section.

22 A number of alternatives can be imagined using utility functions. Again, the transformation must be careful about name conflicts with its own variables, but the transformation has knowledge of all scopes , and therefore can easily avoid conflicts.

5 To project the execution of a function with this alternative, the program must obtain the context object of the function to be projected by calling the function pointed to by the captureUpdate property of this same function.

It will then have to serialize this object context with the same mechanism as previously described.

On returning from the execution of this function, the program will have to update the context thanks to the context object coming from the deserialization that it will pass 10 to the function pointed to by the updateContext property of this same function. 5.2.1.4.

Consistency of objects, ACID execution of a function, ordered execution In the case previously described, a function executed in another execution flow (on a destination execution resource) modifies the objects passed as parameters.

Bearing in mind the fact that this function can be executed asynchronously and in parallel, the execution flow A (calling resource) or another execution flow (other destination execution resource) can during this time modify the parameters. same objects.

This is not possible in a standard javascript system where all the foundations run in the same stream.

In order to maintain the consistency of the objects, by default the functions must preserve the ACID 20 properties (Atomicity, Consistency, Isolation and Durability).

The inventors have therefore developed a technique for preserving these ACID properties.

Thus, in order to execute an ACID property of the function, a differential validation is performed, which consists in particular of checking that: the input parameters of the function and the linked objects have not been modified (on A) from the start execution of the function; 25 - scoped variables and linked objects are unchanged (on A).

To do this, we reuse step 2 (S2) described previously, but applied to stream A.

If the diffa array is empty, then no modification has been made during the execution of the function, we commit (the validation) of the function and we update the object system of stream A (steps 3 (S3) and 4).

If the diffa array is not empty then the function executed by the destination execution resource is invalidated: the updates of the parameters and objects are not propagated and the function is executed again.

23 Thanks to this differential validation, it is possible to asynchronously and parallel execute a function in another stream, while maintaining its consistent execution in the initial application.

Furthermore, let us note that the fact of executing the function asynchronously again does not pose a problem because the function to be executed is itself asynchronous.

5 Another property to observe is the asynchronous execution order relationship which is defined by setimmediate only.

For example the following sequence: setImmediate (fl) setImmediate (f2), setImmediate (f3) Assumes that fl will be executed before f2, and that f2 will be executed before f3.

Also, in the case of a remote execution, as described previously, if f2 or f3 ends before fl, it is necessary to wait for the validation (the commit) of f1 before making the commit of f2, then of f3 .

In this case, the method makes it possible to identify these scenarios by carrying out a specific pass to these aspects during the decomposition of the scripted source code.

Furthermore, during execution, a sequencing of the validations (commits) is carried out in the order of activation and / or the invalidated functions are invalidated / executed if necessary.

Below is a simple example showing the use of this order relation.

The order relation is necessary in order to obtain the good result induced by the causality of the variables of the code. let result = 0; function £ (index) {20 result + = (result * index) + (index * index); setImmediate (f, 1), setImmediate (f, 2).

In this example if the order is respected the result is 7; if the order is not respected it is worth 9.

In the case of this example, on the one hand the compiler (the compilation unit) can avoid dissociating the execution of these functions and on the other hand the allocation unit, if it acts independently of the compilation unit may decide not to transport the execution of these functions to a destination execution resource.

Depending on the embodiments, for developers it is possible to provide a solution for processing the decompositions which is customizable, for example via a specific programming interface (API).

24 From a developer point of view, it is possible to offer the means to execute a function asynchronously with or without ACID guarantee, with or without order guarantee.

The latter calling an end handler.

It is also possible to provide the same support by creating a promise that will perform a simple synchronization point in the code (f (params) .then ()), or the use of await in async functions from above level. 5.3.

Other characteristics and advantages In order to be efficient, the technique described above must make it possible to carry the execution of a large number of functions.

Thanks to the technique of the inventors, Potentially, any asynchronous function is projectable / deportable.

This can be: - functions that are triggered on event (for example .on ('event', f), or setTimeOut or setlmmediate; - async functions; - functions executed in webworkers.

Regarding other synchronous code sequences, they are also projectable / deportable according to their data used.

For example, in a synchronous sequence we have the following behavior in the JavaScript code: - FA - work on a set of data A and production of A '; - FB - work on a data set B and production of 8 '; 20 - FC- work on a set of data This production of C '; - Continued - we continue the code.

It is easy to understand that if A, A 'B, B, Cet C' are different objects / properties, then FA, F8 and FC are projectable / deportable and that it suffices to create a synchronization point before Suite does is running there is no problem on the run.

Thus the work on loops 25 whose functions working on disjoint objects / properties are thus projectable / deportable.

Therefore, this code let samples = []; let out = []; for (let index = 0; index <samples.length; index ++) [30 out [index] = workOn (samples [index]); 25 Can be transformed into a projectable and parallelizable sequence.

Likewise, the Map function defined in javascript is also defined. let newArr = oldArr.map ((val, index, arr) => {// return element to new Array 5 H; Also: f () Preamble ... 10 // working on a dataset A // /. / work on a data set B 15 // Next_ A code transformation allowing the creation of promises, for example, can be used.

The compilation unit generates these transformations based on the ACID property and the order of execution of the functions.

For example: f (- -) Preamble ... async function mf () (async function 's'AH 25 // work on a data set A async function dB (1 // work on a data set B 1 30 let adA = dA (1; let ° dB = dB (); await odA; 26 await ° dB; mf () .then (function () I // Continue ...

5 I); 1.4.

Systems and Implementing Devices Referring to FIG. 5, a simplified architecture of an electronic execution device 10 capable of processing and executing a scripted code is presented.

An electronic execution device comprises a memory 51, a processing unit 52 equipped for example with a microprocessor, and controlled by the computer program 53, implementing the method as described above.

In at least one embodiment, the invention is implemented in the form of an application installed on this device.

Such a device 15 comprises: means for obtaining the scripted code comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least one function executable from a destination execution resource; means for preparing a transmission data structure of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each object of the scripted code, at least one indexing datum; means for transmitting to a destination execution resource, the data structure for transmitting the scripted code; and means for receiving an execution results data structure, implemented after the execution, by the destination execution resource, of the transmission data structure; means for integrating the execution results of the execution results data structure.

Referring to FIG. 6, we present a simplified architecture of an electronic execution device, also called a destination execution resource capable of carrying out transactions using a contextual fingerprint.

Such an electronic execution device comprises a memory 61, a processing unit 62 equipped for example with a microprocessor, and controlled by the computer program 63, implementing the method according to the invention.

In at least one embodiment, the invention is implemented in the form of an application installed on an electronic execution device accessible by a calling resource.

Such an electronic execution device comprises: means for receiving the data structure for transmitting the scripted code; and means for executing the scripted code resulting from the instantiation, in the form of projectable objects, of the received data structure, and means for tracing the results of execution of at least one function contained in these objects ; means for preparing a data structure of execution results of said at least one projectable object of said previously executed scripted code, said data structure of execution results associating with each object modified scripted code, at least one piece of data indexation; means for transmitting to a local execution resource, the data structure of the execution results of the scripted code; These means are in the form of a specific software application, or else in the form of dedicated hardware components.

More particularly, in at least one embodiment,

Claims (10)

CLAIMS 1. A method of executing a scripted code of an application, a method implemented by means of an electronic device, called a calling resource (ResA, A), within which said application is executable, the method comprising: a step of obtaining (20) the scripted code of the application (PCP) comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least one function executable from a resource of destination execution (resX, B); a step of preparing a transmission data structure (PCP #, heap) of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each projectable object of the scripted code, at least one indexing data; a step of transmitting (40), to a destination execution resource, the transmission data structure (PCP #, heap) of the scripted code; and subsequent to the execution (50), by the destination execution resource, of at least one function of said at least one projectable object of the transmission data structure: a reception step (60) of a structure data (ExObj, diff) of execution results of said at least one function; a step of integrating the execution results of the execution results data structure within the calling resource. 2. Method according to claim 1, characterized in that the step of integrating the execution results of the execution results data structure within the calling resource comprises a differential check of the integrity of the data put. updated during execution (50), by the destination execution resource. 3. A method of executing a scripted code according to claim 1, characterized in that the step of obtaining the scripted code comprising a set of projectable objects comprises: a step of obtaining (10) a scripted source code (CSSE), representative of the application to be executed by the calling resource (ResA, A); a step of determining, within the scripted source code (CSSE), at least one function capable of being executed by a destination execution resource, called a projectable function; a step of modifying the scripted source code, delivering a scripted execution code comprising said set of projectable objects, as a function of said at least one previously determined projectable function. 10 4. A method of executing a scripted code according to claim 1, characterized in that the step of preparing a transmission data structure of at least one projectable object of said scripted code comprises: a step of creating d 'an indexing array (refA), for each projectable object (0A, XA) to be transmitted to a destination execution resource (ResX, B), array within which an index (0, 1, ... ) is associated with an object reference (RefOA, RefXA, ...); a step of creating the transmission data structure (PCP, heap) in the form of an array comprising, for each projectable object, an index (0, 1, ...), corresponding to the index (0, 1, ...) of the reference of this projectable object within the indexing array (refA), and a serialized representation (r0, r1, ...) of the projectable object; 20 5. Method for executing a scripted code according to claim 1, characterized in that the step of receiving a results data structure (ExObj, diff) for executing said at least one function comprises: a step of receiving the transmission data structure (PCP #, heap) 25 previously transmitted, in the form of an array comprising, for each projectable object, a corresponding index (0, 1, 2, ...) at index (0, 1, 2, ...) of the reference of this projectable object within an indexing array (refB) of the destination execution resource (ResX, B), and a serialized representation (r0, r1, r2 ...) of the projectable object; a reception step of the data structure of execution results (ExObj, diff) in the form of a table comprising, for each projectable object of the transmission data structure (PCP, heap) previously transmitted, a index (0, 1, 2, ...) and and 3 a serialized representation (VO, r'1, ...) of the modifications performed by said at least one function executed by the destination execution resource (ResX, B). 6. A method of executing a scripted code according to claim 1, characterized in that the step of integrating the execution results of the execution results data structure (ExObj, diff) within the calling resource comprises: a step of updating, within the calling resource (ResA, A), a list of objects, the update comprising creation of a new object when an object is absent the transmission data structure was created by the destination execution resource during execution (50); a step of updating the values of the objects of the list of objects, comprising a check of the consistency of the values to be updated as a function of the original values contained in the transmission data structure. 15 7. A method of executing a scripted code according to claim 3, characterized in that the step of modifying the scripted source code, delivering a scripted execution code comprising said set of projectable objects, as a function of said au at least one predetermined projectable function comprises: a step of determining at least one execution context of said application, as a function of the scripted source code (CSSE), said execution context of said application comprising, for each variable and / or object of the scripted source code (CSSE), a representation of a variable and / or corresponding object, accessible and / or modifiable during projection to a destination execution resource, said execution context taking into account the scope of each variable and / or object of the scripted source code (CSSE); 25 a step of constructing the scripted code (PCP) as a function of the scripted source code (CSSE) and of said previously determined execution context. 8. Electronic device for executing a scripted code, called a calling resource, the device comprising: means for obtaining the scripted code comprising a set of projectable objects, a projectable object of the set of projectable objects comprising at least one function executable from a destination execution resource; 4 means for preparing a transmission data structure of at least one projectable object of said previously obtained scripted code, said transmission data structure associating with each object of the scripted code, at least one indexing datum; 5 means for transmitting to a destination execution resource, the data structure for transmitting the scripted code; and means for receiving an execution results data structure, implemented after the execution, by the destination execution resource, of the transmission data structure; 10 - means for integrating the execution results of the execution results data structure. 9. System for executing a scripted code, characterized in that it comprises at least one calling resource taking the form of an electronic execution device according to claim 8 and at least one remote resource, taking the form a scripted code execution resource accessible from the calling resource. 10. Computer program product downloadable from a communication network and / or stored on a medium readable by a computer and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of the program. A method according to claim 1, when executed on a computer. 25