Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD OF IMPROVING THE MEMORY CONSUMPTION AND EFFECTIVENESS OF A COMPUTER SYSTEM
Document Type and Number:
WIPO Patent Application WO/2005/050343
Kind Code:
A2
Abstract:
The invention relates to a method of improving the memory consumption and effectiveness of a computer system. The inventive method consists in: either partially or completely precalculating the data structures prior to the installation of the computer system, entering said structures directly into a physical memory storage area, and making same available to the system. When the aforementioned data structures comprise variable parts, they are installed in the storage area with constant information, such that the volatile memory locations that contain said variable parts can be referenced during the running of the computer system.

Inventors:
BOUCHY FREDERIC (FR)
Application Number:
PCT/FR2004/002903
Publication Date:
June 02, 2005
Filing Date:
November 12, 2004
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
TRUSTED LOGIC (FR)
BOUCHY FREDERIC (FR)
International Classes:
G06F9/445; G06F9/45; (IPC1-7): G06F/
Foreign References:
EP1098247A22001-05-09
US6110227A2000-08-29
EP1335281A12003-08-13
Attorney, Agent or Firm:
De Saint, Palais Arnaud (35 rue de la Paroisse, Versailles, FR)
Download PDF:
Claims:
Revendications
1. Procédé pour l'amélioration de l'efficacité et de la consommation mémoire d'un système informatique comprenant au moins une unité de mémoire volatile, caractérisé en ce qu'il consiste à précalculer, partiellement ou totalement, des structures de données avant l'installation de ce système informatique, à les inscrire directement dans une zone de stockage en mémoire physique et à les mettre à disposition dudit système, et en ce que, lorsqu'elles comportent des parties variables, ces structures de données précalculées sont installées dans ladite zone de stockage avec des informations constantes permettant de référencer des emplacements en mémoire volatile qui contiennent lesdites parties variables lors de l'exécution du système informatique.
2. Procédé selon la revendication 1, caractérisé en ce que ledit système informatique comporte un environnement de type"Java Card"s'exécutant sur une carte à puce, et en ce que lesdites structures de données précalculées sont des objets dudit environnement"Java Card".
3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend la suppression du code de création de certains objets précalculables lors de l'initialisation de l'environnement JCRE et leur remplacement par des images précalculées de ces objets, stockées dans une mémoire de stockage associée au système.
4. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une séquence comportant les phases opératoires suivantes : une phase préalable comportant : l'identification des objets qui doivent tre créés lors de l'initialisation de l'environnement d'exécution 'un précalcul d'une image d'au moins une partie de ces objets, cette image comprenant : 'une partie entte comprenant une information d'identification indiquant notamment si l'objet contient une partie variable 'une partie fixe contenant éventuellement une information de localisation déterminant un emplacement de la mémoire volatile contenant la partie variable de la valeur de l'objet (si elle existe) 'le stockage en mémoire morte ou non volatile de la partie fixe des images précalculées la substitution de l'objet par son image une phase opérationnelle comprenant : 'éventuellement, la copie totale ou partielle de l'image de l'objet vers une zone d'utilisation plus appropriée la détection des images grâce à l'information d'identification et, lorsqu'on accède à la partie variable d'un objet, l'utilisation de l'information de localisation pour accéder à l'emplacement de la mémoire contenant la partie variable de la valeur.
5. Procédé selon la revendication 2, caractérisé en ce que lesdits objets"Java Card"précalculés sont des objets "Temporary JCRE Entry Point Objects"de type Exception simple ou Exception avec"reason code", ou des objets"Permanent JCRE Entry Point Objects".
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que ladite zone de stockage se trouve en mémoire morte du dispositif informatique.
7. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que ladite zone de stockage se trouve en mémoire non volatile du dispositif informatique.
8. Procédé selon l'une des revendications 1 à 5, caractérisé en que lesdites structures de données précalculées sont utilisées par ledit système informatique directement depuis ladite zone de stockage.
9. Procédé selon l'une des revendications 1 à 5, caractérisé en que lesdites structures de données précalculées sont recopiées totalement ou partiellement de ladite zone de stockage vers une zone d'utilisation avant d'tre utilisées par ledit système informatique.
Description:
PROCEDE POUR L'AMELIORATION DE L'EFFICACITE ET DE LA CONSOMMATION MEMOIRE D'UN SYSTEME INFORMATIQUE.

La présente invention concerne un procédé pour l'amélioration de l'efficacité et de la consommation mémoire d'un système informatique.

Elle s'applique notamment, mais non exclusivement, aux systèmes informatiques miniatures tels que, par exemple, ceux qui équipent les cartes à puce.

On sait qu'une carte à puce est constituée d'un composant électronique ("la puce") encarté dans un support plastique. Ce composant comprend habituellement un microprocesseur, un ou plusieurs périphériques d'entrée/sortie et des moyens de mémorisation.

Habituellement, ces moyens de mémorisation font appel à trois technologies présentes dans le mme composant, à savoir : - la mémoire morte (par exemple ROM) à accès en lecture seule qui présente de bonnes performances pour les opérations de lecture, étant entendu que les opérations d'écriture sont impossibles, - la mémoire non volatile (par exemple EEPROM) à accès en lecture et en écriture : cette technologie présente de bonnes performances pour les opérations de lecture mais de faibles performances pour les opérations d'écriture,

- la mémoire volatile (par exemple RAM) à accès en lecture/écriture qui présente de bonnes performances pour les opérations de lecture et d'écriture.

Les programmes utilisés pour ces composants sont par exemple écrits en langage"Java"TM (lesdits programmes sont alors appelés « applets ») grâce à un environnement de programmation spécifique par exemple de type"Java Card" spécifié par la Société"Sun Microsystems". Cet environnement comprend, entre autres, une machine virtuelle ("JCVM", Java Card Virtual Machine) et une interface programmatique ("API", Application Programming Interface) utilisable par les applets.

L'environnement d'exécution"Java Card" ("JCRE", Java Card Runtime Environment) met à la disposition des applets un certain nombre d'objets appelés"Temporary JCRE Entry Point Objects". Parmi ces objets, on trouve : L'objet APDU (unité de données du protocole d'application) Les objets Exception ("JCRE owned exception objects") Les objets"Temporary JCRE Entry Point Objects"sont en général créés lors de la première initialisation de l'environnement d'exécution. Ils sont alloués en mémoire non volatile, ce qui peut nécessiter de nombreuses opérations d'écriture, opérations coûteuses en temps du fait de la nature de la mémoire non volatile.

L'initialisation de l'environnement d'exécution Java Card JCRE est effectuée lors de la phase de personnalisation de la carte, sur une unité de personnalisation des cartes.

Or, il s'avère que ces unités de personnalisation sont des matériels onéreux, qui doivent tre, si possible, utilisés en flux tendu avec la chaîne de production des puces.

Ainsi, pour ce type d'application, l'invention a donc plus particulièrement pour but d'abaisser le temps requis pour l'initialisation de l'environnement JCRE afin de réduire le temps de personnalisation et de permettre une augmentation des cadences de production des puces.

Néanmoins, l'invention ne se limite pas à un environnement de type"Java Card" : Elle peut tre étendue à tout environnement dans lequel certains objets peuvent tre précalculés.

Elle propose, d'une façon plus générale, un procédé s'appliquant à un système informatique quelconque comprenant au moins une unité de mémoire volatile, ce procédé consistant à précalculer, partiellement ou totalement, des structures de données avant l'installation de ce système informatique, à les inscrire directement dans une zone de stockage, en mémoire physique et à les mettre ensuite, après l'installation, à disposition dudit système.

Avantageusement, dans le cas où lesdites structures de données comportent des parties variables, ces structures de données pourront tre installées dans ladite zone de stockage avec des informations constantes permettant de référencer des emplacements en mémoire volatile qui contiendront, lors de l'exécution du système informatique, lesdites parties variables.

Bien entendu, le système informatique pourra comporter un environnement Java Card s'exécutant sur une carte à puce. Dans ce cas, les structures de données précalculées pourront consister en des objets dudit environnement Java Card.

Les structures de données précalculées pourront tre utilisées par le système informatique directement depuis la zone de stockage. Elles pourront tre recopiées totalement ou partiellement de ladite zone de stockage vers une zone d'utilisation avant d'tre utilisées par le système informatique.

Ainsi, conformément au procédé selon l'invention, le code de création de certains objets précalculables, notamment des objets de type"Temporary JCRE Entry Point Objects"utilisés dans un environnement de programmation de type Java Card pourront tre supprimés lors de l'initialisation de l'environnement JCRE et tre remplacés par des images précalculées de ces objets, stockées dans une mémoire de stockage (mémoire morte ou mémoire non volatile) associée au système.

Dès lors, en supprimant l'allocation en mémoire non volatile, on réduit le temps d'initialisation de l'environnement JCRE.

Cependant, il s'avère que tous ces objets précalculales"Temporaiy JCRE Entry Point Objects"ne sont pas directement utilisables depuis la mémoire ROM. En effet, certains d'entre eux ont une partie variable, ce qui est incompatible avec la nature de la mémoire morte. Tel est notamment le cas du champ d'instance"reason code"de certains objets Exception.

En outre, certains objets, instances d'une mme classe, suivant qu'ils sont des objets de type"Temporary JCRE Entry Point Objects"ou des objets créés par une applet, ont un comportement différent.

L'invention a donc également pour but de résoudre ce problème. A cet effet, le procédé selon l'invention peut comprendre, de manière générale, une séquence comportant les phases opératoires suivantes : - une phase préalable comportant :

'l'identification des objets qui devront tre créés lors de l'initialisation de l'environnement d'exécution un précalcul d'une image d'au moins une partie de ces objets, cette image comprenant : 'une partie en-tte comprenant une information d'identification indiquant notamment si l'objet contient une partie variable 'une partie fixe contenant éventuellement une information de localisation déterminant un emplacement de la mémoire volatile contenant la partie variable de la valeur de l'objet (si elle existe) le stockage en mémoire morte ou non volatile de la partie fixe des images précalculées la substitution de l'objet par son image - une phase opérationnelle comprenant : 'éventuellement, la copie totale ou partielle de l'image de l'objet vers une zone d'utilisation plus appropriée la détection des images grâce à l'information d'identification et, lorsqu'on accède à la partie variable d'un objet, l'utilisation de l'information de localisation pour accéder à l'emplacement de la mémoire contenant la partie variable de la valeur.

Grâce à ces dispositions, le procédé selon l'invention permet d'obtenir les avantages suivants : La réduction du temps de personnalisation. Par exemple, dans le cas de l'application de l'invention au système Java Card, le code normalement utilisé pour la création des objets"Temporary JCRE Entry Point Objects" n'est plus exécuté sur la carte à puce ; ces objets sont directement utilisables depuis la mémoire de stockage ou, éventuellement, depuis la mémoire d'utilisation après copie totale ou partielle.

La réduction de la taille de code. Par exemple, dans le cas de l'application de l'invention au système Java Card, le code utilisé pour la création des objets"Temporary JCRE Entry Point Objects"est remplacé par une image binaire de ces objets mémorisée en mémoire morte ou non volatile.

Lorsque des objets précalculables sont alloués en ROM, l'espace équivalent dans la mémoire non volatile se trouve libéré. Ce procédé s'applique en particulier aux objets de type"Temporary JCRE Entry Point Objects"du système Java Card.

Bien entendu, l'invention ne se limite pas à une utilisation directe des objets précalculés depuis la mémoire de stockage : tout ou partie des objets précalculés peut tre transféré vers une zone de mémoire plus appropriée (mémoire non volatile ou volatile) avant utilisation.

Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif.

Il concerne plus particulièrement la mise en oeuvre du procédé selon l'invention pour certains objets de type"Temporary JCRE Entry Point Objects"de l'environnement de programmation Java Card.

On rappelle qu'un objet Java Card est constitué d'une partie"en-tte"et d'une partie"valeur".

La partie"en-tte"contient les attributs de l'objet, à savoir, de façon classique mais non exhaustive : Son propriétaire ; 'Sa classe (au sens de Java) ;

Une information permettant de déterminer s'il s'agit d'un objet de type "JCRE Entry Point Objects"permanent ou temporaire ; Dans le cas d'un tableau, une information sur le nombre et le type des éléments du tableau ; Dans le cas d'un tableau, une information permettant d'identifier s'il s'agit d'un tableau de type"global array", c'est-à-dire d'un tableau accessible sans restriction d'accès par toutes les applications de l'environnement Java Card.

La partie"valeur"contient la valeur de l'objet, étant entendu que : Dans le cas d'une instance de classe, elle contient les champs de cette instance (les champs statiques de classe ne font pas partie de la valeur de l'objet) ; Dans le cas d'un tableau, elle contient les éléments de ce tableau.

La partie"en-tte"des objets est constante. En effet, une fois qu'un objet a été créé, il n'est généralement pas nécessaire, ni souhaitable, de modifier son en- tte.

La partie"valeur"des objets est soit constante (si tous les champs sont constants), soit variable (si, au moins, un champ est variable).

On considère trois catégories d'objets : 1. Les objets constants. Ces objets, une fois créés, ne sont jamais modifiés.

2. Les objets variables temporaires (ou objets transitoires) : la valeur de ces objets est modifiable. Les modifications ne sont pas conservées par la carte à puce, par exemple après une mise hors tension. La valeur est allouée en mémoire volatile.

3. Les objets variables persistants. La valeur de ces objets est modifiable.

Toute modification est conservée par la carte à puce. La valeur est allouée en mémoire non volatile.

Chaque objet a un propriétaire. Cette information est conservée dans l'entte de l'objet.

Les objets de type"Temporary JCRE Entry Point Objects"appartiennent au JCRE.

Les objets créés par une applet appartiennent à cette applet.

Les objets de type"Temporary JCRE Entry Point Objects"comprennent des objets Exceptions simples et des objets Exception avec"reason code"qui sont définis par Java Card : 1. Les objets Exception simples sont levés par la machine virtuelle lors de l'interprétation du bytecode Java Card ou lors de l'exécution de certaines API Java Card. Une liste de ces objets qui sont des objets constants figure ci-après : s java. lang-ArithmeticException j ava. lang. ArithmeticException j ava. lang. ArrayStoreException j ava. lang. ClassCastException j ava. lang. IndexOutOfBoundsException j ava. lang. NegativeArraySizeException j ava. lang. NuIlPointerException java. lang. SecurityException 2. Les objets Exception avec"reason code", levés par la méthode statique "throwIt"correspondante, dont la liste figure ci-après : Obißs ; ExceE (avec"reåsn ; code," javacard. framework. CardException j avacard. framework. UserException javacard. framework. CardRuntimeException javacard. framework. APDUException j avacard. framework. ISOException j avacard. framework. PINException j avacard. framework. SystemException javacard. framework. TransactionException javacardx. crypto. CryptoException

sont des objets transitoires qui contiennent en général un champ"reason code" qui peut tre lu, respectivement écrit, avec la méthode"getReason", respectivement"setReason". Ces objets appartiennent à l'environnement d'exécution Java Card (JCRE).

Les objets Exception avec"reason code"créés par les applets Java Card sont, contrairement à ceux qui appartiennent au JCRE, des objets variables persistants.

Les objets Exception simple appartenant à l'environnement d'exécution Java Card (JCRE) ne sont constitués que d'une en-tte. Ce sont des objets constants, sans valeur. Ces objets peuvent tre alloués en mémoire morte.

Les objets Exception avec"reason code", qu'ils appartiennent à l'environnement d'exécution JCRE ou à une applet, contiennent en général un champ"reason code"de type"short" (entier non signé sur 2 octets). Grâce aux informations contenues dans l'en-tte de chaque objet Java Card, la machine

virtuelle Java Card JCVM peut déterminer si un objet appartient à l'environnement d'exécution JCRE ou à une applet.

Si l'objet Exception appartient à l'environnement d'exécution JCRE, le champ"reason code"contient une information constante, par exemple un index dans une table, un pointeur, etc., permettant de référencer l'emplacement en mémoire volatile de la valeur effective du"reason code".

Si l'objet Exception appartient à une applet Java Card (et non à l'environnement d'exécution JCRE), le champ"reason code"contient la valeur effective du"reason code".

Ce processus permet, conformément à l'invention, d'allouer les objets Exception de l'environnement d'exécution JCRE en mémoire morte, tandis que le"reason code"effectif associé à ces objets Exception est alloué en mémoire volatile. Il est référencé à l'aide d'une information contenue dans le champ "reason code"persistant.