WO2004061655A1 - Program compaction method employing dynamic code deletion - Google Patents

Program compaction method employing dynamic code deletion

Info

Publication number
WO2004061655A1
WO2004061655A1 PCT/FR2003/003736 FR0303736W WO2004061655A1 WO 2004061655 A1 WO2004061655 A1 WO 2004061655A1 FR 0303736 W FR0303736 W FR 0303736W WO 2004061655 A1 WO2004061655 A1 WO 2004061655A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
program
fragments
memory
deletable
code
Prior art date
Application number
PCT/FR2003/003736
Other languages
French (fr)
Inventor
Renaud Marlet
PHilippe TIGNOL
Original Assignee
Trusted Logic
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44594Unloading

Abstract

The invention relates to a program compaction method employing dynamic code deletion. More specifically, but not exclusively, the invention relates to the compaction of programs which are executed on platforms having small memory resources, e.g. small on-board systems such as chip cards and payment terminals. The inventive method comprises four steps, namely: the determination of fragments of a program which, under certain hypotheses, can be deleted without modifying the semantics; the instrumentation of a program in order to mark fragments which can be deleted and the conditions in which they can be deleted; the optional transformation of the program in order to increase the memory saving that will be produced by the deletion of deletable fragments; and the memory structuring of a program with deletable fragments and the effective deletion of said fragments in order to enable the re-use of the corresponding freed-up memory areas.

Description

COMPACTING PROCESS BY REMOVING DYNAMIC PROGRAM CODE.

The present invention relates to a program compacting process by dynamic removal code.

It more particularly, but not exclusively, to compact programs that run on platforms with low memory resources; this is the case for example of small embedded systems such as smart cards and payment terminals.

This process is particularly suitable for the release of memory resources in these systems and therefore allows the reuse of these so-called memory resources.

It includes four steps:

• the determination of fragments of a program that, under certain assumptions, can be deleted without changing the semantics,

• instrumentation of a program to mark deletable -fragments and the conditions under which they can be removed,

• the possible transformation of the program to increase the memory economy will bring deletion fragments removable, memory • structuring a program with deletable fragments and the actual removal of these fragments to allow the reuse of memory areas corresponding released.

This program of dynamic compaction removal code is particularly useful in the two following cases:

• if, during the execution of a program, one or more fragments of the program are not helpful in following the execution, they can be completely removed. The corresponding memory space and can be recovered for other uses without affecting the behavior of the program.

• deleting one or more program fragments can also be forced at any time. The deleted or fragments, as well as the program portions that exploited these fragments removed, are replaced by code which signals the removal of such fragments to an error is notified in the case where the execution of the program require said fragments . Following the removal code, the program may well lose some functionality. The choice of program fragments to remove therefore achieves a compromise between the features offered by the program and the amount of memory it occupies.

The elimination of programs fragments can be made as many times as necessary during a performance to gain more memory space.

The elimination of programs fragments also a security interest if circumstances want the functionality of a program must become permanently inoperable for safety reasons, it is safer to remove effectively the system memory than to site access control.

The need to save memory is not the only reason for small embedded systems a good target for compaction by removal code; the nature of the programs that run on these systems also contributes. Indeed, it is common for programs loaded on these systems are not executed a single time. This, however, are usually programs with no real ending that endless react to events and orders submitted to them. Now the life cycle of these programs often involves irreversible phases prior initialization. Therefore, fragments of programs that perform these initialization phases become useless after making boots, and can therefore be deleted.

Two common cases such initialization phases are in the case of the smart card: V installation, creating in memory a copy of a executable program, and customizing, which configures this program executable copy for a particular user.

For example, in systems that accept programs "Java Card" language commonly used on smart cards, the installation is done by calling a method (routine) reserved for this single use, named "install" . Once this method called, its content is never executed, except to create a new copy of the same program. Assuming, very common, that the system will never run one copy of the program, the contents of the "install" method can be completely removed, as well as other auxiliary method called only by "install" (not other program methods). The situation is similar for customization. The only difference in the case of "Java Card" is that officials snippets of personalization may not be identifiable by a particular method. However, a widespread system expansion "Java Card", named "Open Platform", introduced a method called "processData" which is only called in the customization phase. Once customization is complete, this method can therefore also be eliminated, just that " 'estab" for the installation phase, under the same assumption.

If the execution of a program fragment deleted remain feasible although prohibited by hypothesis, it is recommended to replace the fragment removed by code that indicates an error. In the case of "Java Card", the deleted code can be replaced, it covers the full content of a method or not, by an exception thrown.

It turns out that the code of dynamic suppression nevertheless raises several questions:

• structuring a program in memory to allow the release of fragments

• determining deletable code fragments into a program,

• instrumentation program to report deletable fragments • the possible transformation of the program to optimize deletable fragments

• the decision of removal of these fragments,

• the effective removal of these fragments, according to their shape,

• the possible restructuring of the resulting program to increase the reusability of areas freed memory. Before we must recall the various features that can be offered by the memory managers that are in execution systems. There are four main types:

• Allocation / release. An ordinary platform program execution is generally provided with a memory manager having at least two features: (1) allocating a memory block, and (2) release a previously allocated memory block. When a block is released, the corresponding memory area can be réexploitée for other uses, including a new memory allocation. For example, in the operating systems of the type "Unix", the "malloc" allocates a given size memory block and returns a pointer to the beginning of the block, and the "free" releases a given block. • recutting. The memory managers also often include resizing features of a previously allocated memory block, reducing the block size by the end. Some systems also allow resizing sometimes by increasing the size of a block at the end. A block can be physically moved or not in memory for this resizing. For example, in such systems

"Unix", the "realloc" performs a reduction (or increase) the size of a block at the end. Reducing the size of the allocated block and to delete a final fragment and release the corresponding memory so it can be reused by the system.

• Dynamic cutting. More rarely, memory managers also can proactively cut into fragments a previously allocated memory block, as if as many blocks were originally allocated separately. Selected fragments can then be released and réexploités by the system. • Defragment. Some memory managers also perform transparently or not for the user, a garbage collection. This operation is to move the memory blocks allocated to group. Defragmentation reduces the number of small gaps between areas of free allocated memory blocks, which are difficult to reuse.

However, moving memory blocks allocated induced constraints on pointers to within blocks. In particular, if the program portions of movements occur, especially after any phase of linking a relogeage addresses and hopping trips may be necessary.

It turns out that to allow the removal of fragments of a program, and especially the efficient reuse of the corresponding memory, we must structure the program in memory wisely. Four typical cases of memory in the representation of management of a program to be considered: the static pre-breaking (before execution) of a program, the dynamic fragmentation (after the performance), the dynamic reduction of block size and restructuring program after deletion fragments.

• Static pre-breaking. If, when loading a program, the system is aware of fragments that can be removed in the future, it can structure the program in memory into several blocks, using for it his usual mechanism of memory allocation. A single memory space is in this case allocated for each reducible moiety, which can then be released separately, without affecting the rest of the program.

• Dynamic Fragmentation. If the program has not received a particular structure when loaded, fragments may still be marked as deleted during runtime. For the corresponding memory areas can be reused, the system can dynamically switching the memory block allocated initially for the program and thus bring the cases above a prefragmented program. • Reduced dynamic block size. However, all systems do not have a strong enough memory manager to achieve the dynamic fragmentation. However, it is a special case that generally know how to treat systems with simple memory management: this is when the memory chip to delete is located at the tail end of the block allocated for the program. In this case, just the system allows an adjustment of the size of memory blocks already allocated. Reducing the size of the block allocated for the program and eliminates the final fragment and release the corresponding memory so it can be reused by the system.

• Defragment. It is also possible to defrag dynamically and explicitly block a program in which areas of code have been removed, without via the memory manager. This operation involves assembling some of the remaining program portions after removal so as to form one or compact blocks, continuous without enclosed region free. This technique is useful in many cases. It is first applicable in systems whose memory manager does not allow an arbitrary dynamic fragmentation but simply a resizing of allocated memory blocks: the remaining program parts are assembled in a compact group in early or blocks and size or the block is adjusted to their content. Defragmentation can also be useful more generally to increase the reusability of freed memory areas. Indeed, many small areas are more difficult to reuse a single large area, which can optionally be redistributed. It should be noted that the movement of stored program portions may require relocating the resulting code. For example, addresses or movement of interblocs jumps must be recalculated. It is a delicate task to perform, both on the machine language of a real microprocessor as the language of a virtual machine. But if whole routines are removed in a program, relocate the remaining code is often much easier because the information to be updated then relate more addresses, travel and indices that identify the routines rather than jumping in the body the same routines.

It turns out that determining deletable fragments can be done in three ways:

1. A programmer who has knowledge of the life cycle of the program, knows from what stages of execution, which fragments programs can be considered deletable.

2. Next languages, fragments of a program are deletable by construction, as is the case for "install" and "processData" in "Java

Card ".

3. Finally an automatic program of treatment to determine fragments of codes no longer useful materially from some points and conditions of execution: this method of determination is the first step of the process described below.

According to the process according to the invention, the program of dynamic compaction is next removal code performs the following four steps: • determination of fragments of a program that, under certain assumptions, can be removed without changing the semantics • instrumentation of a program to mark deletable fragments and the conditions under which they can be removed,

• the possible transformation of the program to increase the memory economy will bring deletion fragments removable,

• Memory in structuring a program with deletable fragments and the actual removal of these fragments to allow the reuse of memory areas corresponding released.

First, the determination of fragments of a deletable program is based on static analysis program.

Vanalyse static program is a set of automatic program processing techniques to determine properties relating to the execution of a program without having to actually run. An extremely common example of static analysis is Y abstract interpretation, studying approximations of running a program.

Automatically determining fragments deletable program by static analysis program may be implemented according to the following operating sequence:

• modeling, as an abstract state, the initial state of an executable copy of the program;

• marking this state as "uncharted";

• As there are one or more non-terminals marked abstract states "not yet explored":

- choice of one of these states; - Marking the selected state as "now explored"; - Abstract program execution from the state taking into account all possible interactions (events and commands received, etc.), which leads to one or more new states; - labeling of these new states as "not yet explored";

- melting states results programs that are similar, generalizing if necessary.

Stopping the algorithm for sure will be implemented as follows:

• modeling the state of a program so that there is a finite number of different configurations, or

• More or less effective generalization resulting states to limit the number of states to consider any state generalizing all others and ensuring that the end of the process can still be forced.

This method allows to construct a directed graph that models the program status transitions. The vertices (or nodes) of this graph are formed by different states met; the edges (or arcs) of this graph represent the calculations and interactions performed by the program, and the program executed corresponding portions.

The program fragments identified as deletable ones are not executable once the program has achieved a certain status. In other words, if there is a vertex of the graph S from which some edges are not available, then the program regions corresponding to these inaccessible edges and not listed among the regions corresponding to the edges S are accessible from deletable when the program execution reaches a state corresponding to S. the identified fragments are deletable without affecting the program semantics, assuming that the program is in its last execution.

The amount and size of fragments deletable program determined by this method depends on several parameters, including:

• the degree of precision with which the program states are modeled,

• the degree of precision with which the interaction with the program are modeled,

• the possible creation of intermediate states between each interaction with the program,

• the conditions of employment of the state generalization to eventually force the termination of the algorithm.

For convenience of memory resources, determination method will usually implemented outside the system of execution of the program, prior to loading. However, nothing prohibits it can take place on the same system.

Second, the instrumentation of the program to mark the deletable fragments, and the conditions under which they can be removed, is performed as follows:

The fragments should first be marked to be known to the system. This marking allows one hand to structure the program in memory in order to promote the removal code, eg with a pre-breaking, and also to designate the fragments to be removed at some point of execution. Marking deletable code areas can be accomplished in many ways. A fragment consisting of a continuous sequence of instructions of a routine can for example be identified by a start address and end address fragment, or a start or end address and a fragment length. A fragment can also be identified by special neutral marks for performance, to indicate the location of the start and the end of a fragment. A fragment consisting of a routine can for example be identified by the name of the routine or memory address.

The code suppression condition associated with a program fragment should also be retained. It can be arbitrarily complex.

The deletion condition can be based on the current program control. This can eg be the address of a program point: when the execution point is reached, then the associated fragment may be deleted. It may also be the designation of a program routine: when this routine is called, or when it returns, then the associated fragment may be deleted.

The deletion condition can also be based on current data handled by the program. This may be for example the designation of a program variable which, when it reaches a certain value, or exceeds a certain threshold, indicates that the associated fragment can be deleted.

The indication to remove fragments may also be present in the same executable code.

In this case, the program reports itself to the system during its execution, a given fragment may be deleted. This type of implementation is particularly well suited for complex removal of conditions because then it has the power of expression of a program to make a decision of removal.

In the case of a "Java Card" system, additional information about deletable fragments of executable code (stored in the "Method Component") can be integrated in a portable way to object program ( "CAP file") as auxiliary program components ( "Custom components"): these components will be ignored by systems that can not handle the compaction removal code.

Third, the possible transformation of the program to increase the memory savings provided by the removal code, is performed as follows:

The déteraiination of deletable program fragments can be automatic or not performed on the same platform for program execution or outside. Following this determination, and the related instrumentation, the program may optionally be automatically processed, without changing its semantics in order to optimize the possibility of reuse of the liberated memory areas. This optimization process is based on several kinds of program changes, various sources of earnings.

The deletable fragments initially separated in the body of the program can be moved to become contiguous. This program transformation reduces fragmentation of programs where it was removed from the code: the total size of the fragments deletable is increased and the number of fragments is reduced. The reusability of the released memory areas is better. This transformation is particularly useful for memory management systems that do not have defragmentation mechanism. The deletable fragments can also be placed in specific routines. As stated earlier regarding the structuring of a program in memory (for defragmentation) facilitates this transformation code suppression mechanism. She does not even require any mechanism if the last routine of the memory block contains the program.

The deletable fragments can also be grouped at the end of the program, in reverse order of removal likely. That is, the fragment that has the best chance of being deleted is placed at the very end of the program block. The following fragment that is most likely to be deleted is placed just before, and so on. This change facilitates the removal code by reducing dynamic block size. For example, in the case of "Java Card", the method could be placed "install" at the end of "Method Component", preceded by the "processData" method.

In the general case, there is no optimal order for scheduling deletable fragments because the choice of removal may depend on dynamic data: there is no sorting better than others. In the case where the deletable fragments are determined by automatic processing program as described above, a suitable sequence is provided by a first of depth-first traversal of the state graph, starting from the initial state, and selection deletable fragments encountered during this course. Some fragments that are deletable according to dynamic data (therefore unknown at the time of scheduling) can be omitted from the removal to arrange a continuous chain of fragments, the subsequent removal is certain.

These changes may require the introduction of hops or routine calls. To the extent that these program changes move the code, they may also require the relogeage program code areas affected by movements.

These transformations can be automated or manual, that is to say, at the discretion of the person preparing the program for compaction by removal code.

Note that these changes are not exclusive of each other; they can be combined.

Regarding the decision removal program fragments, three entities may decide to delete a code fragment: the program, the system and the ADM--ust-tor system.

The program can be instrumented, manually or automatically, to signal to the system that a fragment may be deleted. It is the same program execution which triggers the deletion. Report a fragment is reducible can be implemented in various ways: instruction or group of specialized instructions, call a specific routine of the system, etc. The specification of deletable fragment can be implemented in various ways: appointment of one or more areas of code, a routine or a group of specific routines of daily routine, etc. For example, in "Java Card" method "install" could be completed by the call to a method of the system that would signal that the running method is not useful and can be deleted.

The system, if it has information about the possible removal program fragments during execution (that these fragments and conditions of removal were determined automatically or not), can take the initiative to remove some of these fragments once the relevant conditions are met. The person who manages the system can also force the deletion of some program fragments. In this case, the system must have a command to stipulate program fragments to delete.

These three sources of choice are not exclusive of each other; they can be combined.

Fourth, the memory structure of a program with deletable fragments and the actual removal of these fragments to allow the reuse of the corresponding freed memory areas is done as follows:

Once the decision to remove some fragments, the release of the corresponding memory areas becomes effective only in terms of the actual structure of the program in memory. It comes down to the following:

• If the program is statically prefragmented, each fragment to be removed is released individually, with the system memory manager.

• if the system memory manager enables dynamic fragmentation, the program is fragmented and fragments flying to remove are released individually, as in the previous case.

• if the fragments to be removed are located at the end of memory blocks, the corresponding memory space is freed by resizing the blocks to reduce its size.

• if the system is equipped with a mechanism to relocate the code, all undeleted elements of the program gathered at the start block, relocated, and the block is resized to reduce its size. These different types of actual removal are not exclusive; they can be combined.

If a code fragment can be removed without the program semantics is preserved (the program loses some of its features), it is recommended to set up a monitoring mechanism. An error will be notified if and program implementation requires a deleted fragment. To do this, one can for example replace the removed code by code that raises an error.

If a fragment removed to be replaced by code that indicates an error, a new memory block may be allocated for this purpose. Alternatively, the deleted block can also be reused by resizing it to fit to the size of code which signals the error.

Thus the proposed method according to the invention is particularly suitable for the release of memory resources on platforms such as small embedded systems and therefore allows the reuse of these so-called memory resources.

Claims

1. Program compacting process by dynamic removal code, characterized in that it comprises the following steps:
• the determination of fragments of a program that can be deleted or without changing the semantics when the program is in its last execution either by modifying the semantics when these changes are acceptable, • instrumentation of a program to mark deletable fragments and the conditions under which they can be removed,
• Memory in structuring a program with deletable fragments and the actual removal of these fragments to allow the reuse of memory areas corresponding released.
2. Method according to claim 1, characterized in that before the aforesaid structure in memory of a program, the method comprises converting the program to increase the memory saving will bring deleting deletable programs.
3. A method according to claim 1, characterized in that the said determination of fragments deletable program is automatically performed by static analysis program.
4. A method according to claim 3, characterized in that the said determination of fragments deletable program is from a directed graph constructed in accordance with the following operating sequence: • modeling the form of an abstract state of initial state of an executable copy of the program;
• marking this state as "uncharted";
• As there are one or more non-terminal abstract states marked as "not yet explored":
- choice of one of these states;
- Marking the selected state as "now explored";
- Abstract program execution from the state taking into account all possible interactions and producing one or more new states;
- labeling of these new states as "not enclose explored";
- melting states results programs that are similar, generalizing if necessary; the nodes of the graph being constituted by different states encountered in the above process sequence, arcs between two states of the graph representing the program portions executed to switch from one state to another in the above process sequence, and fragments deletable being the corresponding program portions to the arcs which are no longer visible from a certain node on condition that the execution leads to the state represented by this node.
5. The method of claim 4, characterized in that the stop of the said sequence with certitude is implemented according to at least one of the two following processes: • modeling the state of a program to that there is a finite number of different configurations,
• generalization of the resulting states to limit the number of states to consider any state generalizing all others and ensuring that the end of the process can still be forced.
6. A method according to claim 4, characterized in that it comprises determining fragments deletable program which is carried out according to one or more of the following parameters: • the degree of precision with which program states are modeled ,
• the degree of precision with which the interaction with the program are modeled,
• the possibility of creating intermediate states between each interaction with the program,
• the conditions of employment of the state generalization to force the termination of the algorithm.
7. A method according to claim 1, characterized in that the instrumentation program consists of one or more of the following information:
• auxiliary data do not alter the implementation of the program and intended to be used by the runtime system,
• additional instructions included in the body of the program to be executed in the same way as ordinary program instructions.
8. The method of claim 1, characterized in that it comprises a marking made deletable fragments as follows:
• locating a start address and an end address of the fragment, and / or
• locating a start or end address and the length of the fragment, and / or • locating a routine identifier, and / or • the introduction of special marks, neutral for performance, for indicate the location of the beginning and end of a fragment.
9. A method according to claim 1, characterized in that the conditions for removing are based on:
• the current program control, and / or
• routine data handled by the program.
10. The method of claim 2, characterized in that the processing of the program to increase the memory saving provided by the removal code is performed according to at least one of the following possibilities:
• moving deletable fragments initially separated in the body of the program, to become contiguous, "positioning deletable fragments in specific routines
• grouping the deletable fragments at the end of program block in the reverse order of removal likely.
11. Method according to one of claims 4 and 10, characterized in that, in the case where the deletable fragments are determined by static analysis of the program, an appropriate deletion command is provided by a first depth-first traversal of the graph state, starting from the initial state, and a selection of deletable fragments encountered in this course.
12. The method of claim 10, characterized in that some fragments which are deletable based on dynamic data, may be omitted from the removal to convert a continuous chain of fragments whose successive cancellation is certain.
13. The method of claim 1, characterized in that the memory structure of a program with fragments deletable and the effective removal of these fragments to permit reuse of the corresponding released memory areas are made according to at least one of the four following types of deletion:
• If the program is statically prefragmented, each fragment to be removed is released individually, with the system memory manager
• if the system memory manager enables dynamic fragmentation, the program is fragmented and fragments flying to remove are released individually, as in the previous case,
• if the fragments to be removed are located at the end of memory blocks, the corresponding memory space is freed by resizing the blocks to reduce its size, • if the system is equipped with a mechanism to relocate the code, all unassigned deleted from the program gathered at the start of block, relocated, and the block is resized to reduce its size.
14. The method of claim 1 intended to be implemented in embedded systems, characterized in that a program running on fragments deletable these aforementioned systems is structured in memory according to the information provided by the instrumentation of the program and in that deletable fragments are effectively removed when the conditions specified by the instrumentation of the program are met.
PCT/FR2003/003736 2002-12-18 2003-12-15 Program compaction method employing dynamic code deletion WO2004061655A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0216253A FR2849229B1 (en) 2002-12-18 2002-12-18 program by dynamic compaction Method removal code
FR02/16253 2002-12-18

Publications (1)

Publication Number Publication Date
WO2004061655A1 true true WO2004061655A1 (en) 2004-07-22

Family

ID=32406232

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/003736 WO2004061655A1 (en) 2002-12-18 2003-12-15 Program compaction method employing dynamic code deletion

Country Status (2)

Country Link
FR (1) FR2849229B1 (en)
WO (1) WO2004061655A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0996059A2 (en) * 1998-10-19 2000-04-26 International Business Machines Corporation Class loading model
US6170083B1 (en) * 1997-11-12 2001-01-02 Intel Corporation Method for performing dynamic optimization of computer code
US6247175B1 (en) * 1998-12-22 2001-06-12 Nortel Networks Limited Method and apparatus for identifying and removing unused software procedures
US20020013938A1 (en) * 2000-02-09 2002-01-31 Evelyn Duesterwald Fast runtime scheme for removing dead code across linked fragments
US20020029357A1 (en) * 1998-11-16 2002-03-07 Insignia Solution, Plc Method and system of memory management using stack walking

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6170083B1 (en) * 1997-11-12 2001-01-02 Intel Corporation Method for performing dynamic optimization of computer code
EP0996059A2 (en) * 1998-10-19 2000-04-26 International Business Machines Corporation Class loading model
US20020029357A1 (en) * 1998-11-16 2002-03-07 Insignia Solution, Plc Method and system of memory management using stack walking
US6247175B1 (en) * 1998-12-22 2001-06-12 Nortel Networks Limited Method and apparatus for identifying and removing unused software procedures
US20020013938A1 (en) * 2000-02-09 2002-01-31 Evelyn Duesterwald Fast runtime scheme for removing dead code across linked fragments

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ARNOLD M ET AL: "Online feedback-directed optimization of Java" 17TH INTERNATIONAL CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, SYSTEMS, LANGUAGES AND APPLICATIONS (OOPSLA 2002), SEATTLE, WA, USA, 4-8 NOV. 2002, vol. 37, no. 11, novembre 2002 (2002-11), - 8 novembre 2002 (2002-11-08) pages 111-129, XP002251020 SIGPLAN Notices, Nov. 2002, ACM, USA ISSN: 0362-1340 *
TIP F ET AL: "Practical experience with an application extractor for Java" CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, SYSTEMS, LANGUAGES AND APPLICATIONS (OOPSLA'99), DENVER, CO, USA, 1-5 NOV. 1999, vol. 34, no. 10, octobre 1999 (1999-10), - 5 novembre 1999 (1999-11-05) pages 292-305, XP002251021 SIGPLAN Notices, Oct. 1999, ACM, USA ISSN: 0362-1340 *

Also Published As

Publication number Publication date Type
FR2849229B1 (en) 2005-02-25 grant
FR2849229A1 (en) 2004-06-25 application

Similar Documents

Publication Publication Date Title
US5819298A (en) File allocation tables with holes
US6075940A (en) System and method for pre-verification of stack usage in bytecode program loops
US6910213B1 (en) Program control apparatus and method and apparatus for memory allocation ensuring execution of a process exclusively and ensuring real time operation, without locking computer system
US6714949B1 (en) Dynamic file system configurations
US6820101B2 (en) Methods and apparatus for optimizing garbage collection using separate heaps of memory for storing local objects and non-local objects
US5813011A (en) Storage of a compressed file containing its own compression management table
US6131192A (en) Software installation
US20030033441A1 (en) Highly componentized system architecture with a demand-loading namespace and programming model
US5623661A (en) System for and method of providing delta-versioning of the contents of PCTE file objects
US6363522B1 (en) Method and apparatus for handling exceptions as normal control flow
US6757890B1 (en) Methods and apparatus for enabling local Java object allocation and collection
US5652883A (en) Computer method and system for conservative-stack and generational heap garbage collection
US6112280A (en) Method and apparatus for distinct instruction pointer storage in a partitioned cache memory
US6275916B1 (en) Object oriented program memory management system and method using fixed sized memory pools
US7143124B2 (en) Detection of dead regions during incremental collection
US5835768A (en) Computer operating system providing means for formatting information in accordance with specified cultural preferences
US6092163A (en) Pageable filter driver for prospective implementation of disk space quotas
US5832273A (en) System for deleting redundant instructions from high level language source code containing in-line assembly instructions
US6272674B1 (en) Method and apparatus for loading a Java application program
US6704746B2 (en) Method and apparatus for lazy instantiation of objects in a virtual machine
US20120233592A1 (en) Meta Garbage Collection for Functional Code
US6243864B1 (en) Compiler for optimizing memory instruction sequences by marking instructions not having multiple memory address paths
US20020073404A1 (en) Method and apparatus for storing long-lived objects in a virtual machine
US6948059B1 (en) Component loader for industrial control device providing resource search capabilities
US6938140B2 (en) System and method for linear object reallocation in place

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct app. not ent. europ. phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP