WO2006077252A2

WO2006077252A2 - Escape analysis in an object oriented language program for a virtual stack machine

Info

Publication number: WO2006077252A2
Application number: PCT/EP2006/050350
Authority: WO
Inventors: Antoine Galland
Original assignee: Gemplus
Priority date: 2005-01-21
Filing date: 2006-01-20
Publication date: 2006-07-27
Also published as: FR2881240A1; FR2881240B1; WO2006077252A3

Abstract

The invention relates to an escape analysis method consisting in carrying out a static escape analysis on an intermediate execution language program for a virtual stack machine (201) in a first processing device and in generating escape signatures associated to the program methods according to escape rules (202), in loading the generated escape signatures and a program (203) in a second processing device provided with a virtual stack machine, in carrying out a partial escape static analysis (204) based on the loaded signatures, in generating test escape signatures according to said escape rules and in checking (205), for a given method, the coherence between the test and loaded escape signatures thereof. Said invention makes it possible, in particular, to limit an escape analysis carried out on a second device ensuring the integrity of the loaded program.

Description

EXHAUST ANALYSIS IN A PROGRAM IN ORIENTED LANGUAGE OBJECT FOR VIRTUAL MACHINE WITH BATTERY

The invention relates generally to computer programs, and in particular to exhaust analysis methods in object-oriented programs for stacked virtual machines.

The exhaust analysis is performed on a program to determine the lifetime of objects. An escape analysis allows possible optimizations during execution, for example memory management in stack of objects or elimination of synchronization.

A garbage collection function (referred to as garbage collection in English) is integrated into a virtual machine to retrieve memory locations that have ceased to be used by a program. A garbage collector scans all the memory locations that have been allocated to objects in a dedicated memory space. Locations that have become unused are then identified. When an object is no longer pointed to by any other object, its locations are considered unused. These memory locations are then marked so that they can be reallocated to another process in the program. The recovery of memory space requires a large number of operations and the recovery of memory space by the garbage collector can then occupy an excessive portion of the processing capacity of a device with limited processing capacity. The time required for space recovery in a non-volatile memory can also be important, because of their long writing time.

The object of the invention is to adapt the program exhaust analyzes in order to implement this type of analysis by means of a device whose processing capacity does not allow it with the known techniques of analyze all the methods of the program. The invention also aims to guarantee the integrity of the result of the exhaust analysis. The invention thus relates to an exhaust analysis method, comprising the steps of:

in a first processing device, performing a static exhaust analysis on an intermediate runtime program for a stacked virtual machine and generating escape signatures associated with respective methods of the program according to escape rules predetermined;

in a second processing device equipped with a stack virtual machine: load the generated escape signatures and the program;

performing a partial escape static analysis based on the loaded signatures and generating, according to said predetermined escape rules, test escape signatures associated with the methods provided with an escape signature; - for a given method, check the consistency between its test escape signature and its loaded escape signature. According to one variant, the second processing device used is a device with limited processing capacity.

According to another variant, an escaping signature generated for a method includes information associated with its parameters such as its arguments, its current object and / or its return object.

According to another variant, the partial exhaust static analysis and the consistency check are performed after the loading of the program into the second processing device. According to yet another variant, the program in intermediate execution language is in the form of Java or CLI pseudo-binary code.

Other characteristics and advantages of the invention will emerge clearly from the description which is given hereinafter, by way of indication and in no way limitative, with reference to the appended drawings, in which: - Figure 1 schematically illustrates two processing devices implemented in the invention;

FIG. 2 illustrates the process steps of analysis of a program according to the invention; FIG. 3 illustrates escape rules on instructions of a Java pseudo-binary code;

FIGS. 4 to 6 illustrate a Java code and the static exhaust analysis carried out on its pseudo-binary code equivalent;

FIG. 7 illustrates a static analysis and a verification carried out in a processing device loading the program.

The following notions will be used later:

An object o is said to be unescaped (or captured) by a method m in which it has been allocated only if its lifetime does not exceed that of method m. A captured o allocation can be safely destroyed at the exit of this method m. The memory locations occupied by the captured object o can be released at the end of the execution of the method m. In contrast, an escaped object o is an object that can potentially be referenced after the completion of the method m in which it was allocated. A device with limited processing capacity will designate a processing device whose processing capacity is insufficient to carry out the static exhaust analysis on the entire program on its own. For example, a device with a limited processing capacity will have a RAM less than 32 kilobytes and an EEPROM of less than 512 kilobits.

The invention proposes an exhaust analysis method in which a static exhaust analysis is performed on an intermediate runtime program for a stacked virtual machine in a first processing device. Escape signatures associated with the program methods are generated according to predetermined escape rules. The program and the escape signatures are loaded into a second processing device and a partial exhaust static analysis, based on the loaded exhaust signatures is performed. Test signatures associated with the objects of the loaded program are generated by the same predetermined escape rules. The consistency between the loaded escape signatures and the test escape signatures is then checked. The integrity of the loaded program is thus verified. The loaded escape signatures can not be fraudulently used to circumvent security rules on object references.

The invention provides an achievable exhaust analysis method on a form of the usually available program and limiting the resources required to perform the exhaust consistency check.

Figure 1 illustrates an exemplary system implementing the invention. A first processing device DTA is formed of a computer. The DTA device is connected to an LEC chip card reader, through which it can communicate with the second DCTL processing device formed of a smart card. The processing device DTA has a program in intermediate execution language, intended to be subjected to the method of static analysis of exhaust and loading into the device DCTL.

An example of a method embodying the invention is illustrated with reference to FIG. 2. The exhaust analysis will be illustrated on the instructions of the Java virtual machine (in English named bytecode Java, described in the specification named "The Java Virtual Machine Specification "written by Tim Lindholm and Frank Yellin at The Java Series editions, Addison-Wesley (1st ed.) In 1996).

In step 201, the first processing device DTA performs a static exhaust analysis on the program in the form of pseudo-binary code. The static exhaust analysis aims to determine the lifetime of objects and aims to generate escape signatures summarizing the escape behaviors. For each method m we generate two escape signatures, one named direct and noted Se "1 and a second named unified and noted [Se] w. The signatures focus on the call parameters of a method that are in order: the current object "this", the arguments arg 1, ..., arg _n and the return object returned by the method called "return".

The static exhaust analysis performed in the first DTA processing device can be performed as follows. The static exhaust analysis establishes a graph of the control flow of the program and runs through this abstract representation of the program. A graph of the call methods and their interactions is thus established in order to perform an inter-method analysis and an execution graph of each method is established in order to perform an intra- method analysis. Known methods for estimating control flow graphs of object-oriented languages can be used for this purpose. The static exhaust analysis coordinates intra-method analysis and inter-method analysis. Indeed, to determine the behavior of a method m using another method m ', it is necessary to also study the behavior of this other method. Object escape hypotheses are adopted at the beginning of the analysis (the initial hypotheses assume that all the objects are captured), then these hypotheses are updated incrementally during inter-method analysis. When the escape hypotheses converge to a fixed point, the static exhaust analysis is interrupted.

We will then detail the intra-method analysis performed. The analysis uses an abstract interpreter associating evaluation rules for each instruction of the program. The abstract interpreter executes the instructions of the Java virtual machine by following the program's control flow. Intra-method analysis evaluates the instructions of a method in isolation, method by method, without knowing the behavior of other methods. The interpreter can be represented by a set of transition relations: i: (R, P) => (R ', P') where i is the evaluated instruction, R and P respectively represent the value of the registers and the stack before the execution of i, and R 'and P' their value after its execution. For simplification, the registers and cells of the stack manipulate values that are noted v. These values include both base types (integer, boolean ...) as well as object or table references.

For example, the instruction aload_k duplicates the contents of the register k at the top of the stack: aloacLk: (R {k = v}, P) => (R {k = v}, P.v)

After executing the statement, the register Rk and the stack vertex therefore contain the same value v. The inverse statement, astore_k, unpacks the value v at the top of the stack to place it in the register k: astore.k: (R, P.v) => (R {k - v}, P)

v is thus defined as being the set of references contained in a register or cell of the stack at a point p of the execution of the program. An alias analysis between the registers follows the contents of the registers at each point p of the execution of the program. These references r come from allocations, and marked by the point of the program that created them r _p . At each instruction of the Java binary pseudo-code, an escape rule is associated. An allocation in p stacks on the stack a reference defined to captured r _p : J .. (the sign J. will designate later the smallest element of the lattice is a reference defined as captured). new: (R, P) => (R, Pv) such that v = {r _p } and r _p : _L An instruction has potentially several predecessors. Thus, the state of the registers and the stack before evaluation of i is the union (denoted u) of the states of the predecessors of i after their evaluation. If we designate instr (p) for the instruction at the program point p, in (p) the state before and out (p) that after, the system of equations of the exhaust analysis for each point p of the The program is: instr (p): in (p) => out (p) in (p) = u (out (q)), q being a predecessor of p;

with as starting point for in (po) the data of the escape signature Sem (escape of call parameters and connection between call parameters).

The unification of two values v U v 'is the union of their set, without duplicates. The equations are then solved by a standard iterative algorithm until the fixed point is reached. For simplicity, a global list of the values L resulting from the allocations is maintained during the analysis (at the beginning of the analysis, this list is defined empty). When the reference of an allocation escapes, it is removed from the list. L then corresponds to all the references captured L

= {r _p I r _p : J.}. According to a detailed optimization later, the allocations corresponding to these references can be managed by stack management.

In addition to the registers and the stack, a connection graph G is constructed which indicates the existing memory connections between the reference values manipulated by the program. The data structure G makes it possible to process the assignments. Let V be the set of values, we define G such that G: V → P (V) where P (V) is the set of parts of V. The graph is updated during the putfield and aastore assignments by establishing a connection between the destination value Vd and the assigned value v _a . This connection is added to those already existing since

Vd. The areturn statement updates G to establish the escape signature on the parameter connections for the returned object. With regard to reading an object field or a table cell, getfield and aaload instructions, the values pointed by v denoted by G (v) are mounted in stack height. The escape of a value v during the evaluation of an instruction i is denoted by esc (v) = T such that V r _p ev, r _p = T. In addition, the escape of a value v milk escape by reachability all values accessible from v such that esc (G (v)) = T. Figure 3 illustrates escape rules on the pseudo-binary code

Java applied to a number of instructions and used to generate the Sem and [Se] w escape signatures.

Whatever the information of the intra-method analysis, the operation of the inter-method analysis is similar. The intermethod analysis calculates a signature for each method that has undergone an intra-method analysis, this signature being valid whatever its context of call. Inter-method analysis is a static analysis by abstract interpretation interacting with that of intra-method analysis. The signature data are semi-lattices. Their structures are derived from those specified in the intra-method analysis. For signature generation, at the outset, the escape signature is defined as the smallest element of the lattice. Then, the inter-method algorithm processes the methods one after the other. For each method, an intra-method analysis is performed, the result of which gives the new escape signature.

In an intra-method analysis of m, let in (Se ") be its input signature and 0Ut (Se") that output, if in (Se ") C out (Se") (at least one of the parameters the signature has progressed in its semi-lattice) then a second intra- method analysis must be performed on m as well as on the methods calling m. Thus, as long as the global fixed point of the signatures is not reached, the inter-method analysis is continued. The interaction between the inter-method and intra-method analyzes makes it possible to generate the fixed point of the Sem and [Se] w escape signatures.

We will now define the escape signature on the call parameters. Let Sem 'the escape signature of the method m' called during the analysis of m. This first signature is defined on the call parameters by:

T if v _P ar_k escapes by m 'VkeO ... nl Sem (v _by k) =

-L otherwise

The starting point of the intra-method analysis for a method m is based on its own Sem escapement signature:

In (po) = ((Vpar_0, ..., V _pa r_n-1, V _e , ..., V _e ), e) such that esc (v _pa r_k) = S "(v _P ar_k) for k = 0 ... n - 1 and esc (v _e ) = _L with V _P ar_k = {r _P ar_k} θt V _e = {} where r _pa r_k symbolizes the passed reference in argument which is encapsulated in the structure of value to perform alias analysis on the registers. Initially, each of its symbolic references on the parameters is added to the list L. At the end of an intra-method analysis pass, the parameters remaining in the list L serve to update the new signature. During a method call, an escape signature is applied to the arguments of the stack.

When one knows exactly the method called (invokespecial and invokestatic) the calculated signature Sem 'is applied on the elements of the stack. In the case of virtual methods (invokevirtual and invokei interface), we apply the unified signature noted [Se \ m '' computed from the signatures of the m "callable methods such as:

[Se] m '(Vpar_k) = U _m ^» appliables Sθ» i''(v _by _k)

We will now define the escape signature on the connections between the call parameters. This signature on the connections between the parameters extends the previous signature on the escaping parameters. This signature exposes outside a method m the connections between the call parameters established during the intra-method analysis:

T if there is a connection between v _by k and v _by j VkjeO ... nl Sewi '(G (v _by k, v _pa rj)) =

-L otherwise

The starting point of the intra-method analysis becomes: in (po) = ((v _by _o, ..., v _by _ _n -i, v _e , ..., v _e ), e) such that esc (v _by _k) = Sewî (v _by _k) for kj = O ... n - 1 and esc (v _e ) = J. with v _by _k = {r _by _k}, v _e = {} and G (r _by _k) = {r _by j} when

Sew (G (v _by _k, v _by j)) = T

Figure 4 illustrates an example of Java code in which the allocation at point 1. is escaped and whose allocation at point 2. is not escaped. FIGS. 5 and 6 illustrate the use of the static analysis rules, rules described with reference to FIG. 3, on each instruction of the methods of the associated Java pseudo-code.

The signature Se of the id () LC input method is: J. OL without connection. At the output, the signature SE id () LC is J- OL with a connection _re r tum to RTM _S. The right column shows the evolution of list L and connection graph G. The signature Se of the facto ry () LC method taken as input is: J. OL without connection. The analysis of the factory () LC milk method calls for the signature Se of id () LC. The signature Se output of the method facto ry () LC is: -L OL without connection, the allocation of the point p ₄ is non-escaped and that of the point p ₀ is escaped. Indeed, at the moment of the instruction areturn during the call to the id () LC method at the point p ₁₀ , the reference rin _VO ke_pio escapes and by reachability, G (invoke_pio) = {r _p0 } makes escape r _p0 .

Following the exhaust analysis, escape signatures are thus obtained for at least some methods in step 202.

As detailed in the examples above, for a predetermined method, the escape signatures advantageously comprise escape information concerning various parameters: its arguments, its current object or its returned object. An escape signature may thus include the following information:

escape definitions defining whether an object is captured by the method for all its parameters;

a memory link reference defining whether, for each combination of two parameters defined in the signature, one refers to the other in the program. This information makes it possible to determine the following escape case: if an object is referenced by an escaping object, then it escapes as well.

Virtual method calls can make the prediction made during the improper static exhaust analysis. To remedy this, we generated for each method the direct escape signature Sem and the unified escape signature [Se] m.

The direct escape signature concerns an execution trace performed during the static analysis: this signature could be used by the second DCTL device if the type of the object is exact. The type of the object is exact, if during its lifetime, its dynamic type is equal to its statistically declared type.

The unified escaping signature makes a prediction in the worst case, by unification of different possible execution traces: this escape signature can be used by the second device DCTL if, during a method call, the type of an object has varied since its creation. For example, the unified escape signature is generated by performing the unification of the direct escape signatures for all the methods that can be called at this point of the program. Thus, even if the unified escape signature does not correspond exactly to the execution conditions of the program, its escape indications are sufficiently approximate not to determine an erroneously captured object. The unified escape signature is generated by browsing the inheritance tree and method overload. Of course, the use of the unified escape signature makes it possible to deduce a smaller number of captured objects than the use of the direct escape signature. At runtime, the DCTL device will use either one of the escape signatures based on the static calls declared in the pseudo-code or based on type information obtained from a pseudo-pseudo verification. code, as detailed later.

The skilled person will limit the number of methods to optimize to keep a program load of reasonable size. Thus, the skilled person can reserve the generation of escape signatures methods with the best optimization prospects during execution.

Step 203 comprises loading the program and escape signatures into the DCTL processing apparatus, a partial static exhaust analysis leading to the generation of test escape signatures and a consistency check between the signatures of loaded exhaust and test exhaust signatures. Partial static analysis Exhaust uses the same exhaust analysis rules as those used in static DTA analysis.

As illustrated in FIG. 7, to perform the escape coherency check, the loaded escape signatures are used as assumptions for intra-method static escape analysis in step 204.

During the intra-method analysis of the method m, its loaded signature is used as its input signature in (Se ") is taken as input and the signature

is output as the test signature. When calling the method m ', the loaded Sem' signature is used to continue the intra-method analysis on m.

Then, step 205 is compared with the exhaust signature loaded at the test exhaust signature obtained. If all the escapements defined in the loaded signature are included in the set of escapements defined in the test signature Stm, it is considered that there is coherence between the loaded exhaust signature and the exhaust signature of test: the use of the loaded escape signature is not likely to erroneously determine an object as captured by the method. It is thus possible to check the integrity of the program and the loaded signatures.

Since only the intra-method analysis is performed by the DCTL, the amount of resources it needs to implement the partial static analysis and the exhaust consistency check can be limited. The integrity of the program can therefore be verified in a reasonable time even with a device with limited resources, such as a smart card. The processing device DTA thus advantageously has treatment capacities that are significantly greater than those of the processing device DCTL.

Direct signatures concerning the methods of the program can be generated in the DTCL device by a pseudo-binary code verifier available where appropriate. The verification can then be performed taking into account either the loaded direct escape signature or the unified escaped signature loaded. When an inconsistency is detected during the verification, it can be expected that the virtual machine blocks the further loading of the program, blocks the subsequent execution of the program or blocks the realization of a program optimization based on the escape signatures . Optimization may also be limited to methods for which the consistency check has yielded a favorable result.

Although it is possible to perform the escape coherency check during the execution of the program, in practice an escape consistency check performed during or just after the loading of the program in the DCTL processing device will be preferred.

Although a loading of the program has been shown from the processing device performing the first static exhaust analysis, loading will generally be performed from another machine on a production line.

At the end of the method according to the invention, the virtual machine of the processing device of the device DCTL exploits the loaded escape signatures in order to determine optimizations of the execution of the program.

The virtual machine can in particular determine, on the basis of the loaded escape signatures, the captured objects that can be managed in memory with a function different from the crumb management of the virtual machine. In order to lighten memory management, it is possible in particular to manage these objects by stack allocation. The allocation and deallocation of stacked objects follows the stack of call methods. The allocation of each captured object is at the top of the stack. The deallocation is performed globally at the exit of the method in which the captured objects were allocated.

The virtual machine can still be used for eliminating synchronizations from escape signatures. An object captured by a method is accessed by a single process, so it does not require access synchronization mechanisms (lock management and mutual exclusion mechanisms). The elimination of synchronization eliminates the elements of unnecessary synchronization to optimize scheduling and concurrency management in the DCTL device.

The virtual machine executes the program taking into account the optimizations determined previously.

Claims

An exhaust analysis method, characterized in that it comprises the steps of: in a first processing device, performing a static exhaust analysis on a program in intermediate execution language for virtual machine to stack (201) and generating escape signatures associated with respective methods of the program according to predetermined escape rules (202);

in a second processing device equipped with a battery virtual machine:

- load the generated escape signatures and the program (203); performing a partial escape static analysis (204) based on the loaded signatures and generating, based on said predetermined escape rules, test escape signatures associated with the methods provided with an escape signature; for a given method, checking (205) the consistency between its test escape signature and its loaded escape signature.

2. Method according to claim 1, wherein the second processing device used is a device with limited processing capacity.

The method of claim 1 or 2, wherein an escape signature generated for a method includes information associated with its parameters such as its arguments, its current object and / or its return object.

A method as claimed in any one of the preceding claims, wherein the partial escape static analysis and the consistency check are performed after the program has been loaded into the second processing device.

5. Method according to any one of the preceding claims, wherein the program in intermediate execution language is in the form of Java or CLI pseudo-binary code.