FR2883390A1 - Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie - Google Patents
Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie Download PDFInfo
- Publication number
- FR2883390A1 FR2883390A1 FR0502561A FR0502561A FR2883390A1 FR 2883390 A1 FR2883390 A1 FR 2883390A1 FR 0502561 A FR0502561 A FR 0502561A FR 0502561 A FR0502561 A FR 0502561A FR 2883390 A1 FR2883390 A1 FR 2883390A1
- Authority
- FR
- France
- Prior art keywords
- memory
- rules
- placement
- data structures
- programming language
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44568—Immediately runnable code
- G06F9/44573—Execute-in-place [XIP]
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne un procédé de gestion du placement de structures de données en mémoire dans un système informatique, caractérisé en ce qu'il comprend une étape de déclaration (10) d'un ensemble de règles de placement desdites structures de données en mémoire par l'intermédiaire d'un langage de programmation dédié à cet effet.
Description
GESTION DU PLACEMENT DE STRUCTURE DE DONNEES EN MEMOIRE
BASEE SUR UN LANGAGE DE PROGRAMMATION DEDIE
La présente invention concerne, de manière générale, le domaine de la gestion mémoire dans les systèmes informatiques et:, plus particulièrement, concerne la gestion du placement de structures de données en mémoire dans les systèmes embarqués tels que les appareils électroniques portables dotés d'un microcontrôleur réunissant un processeur et des mémoires de différents types.
A l'heure actuelle, l'organisation du contenu d'une mémoire est essentiellement basée sur des structures de données (fichiers, objets...), représentant une organisation des données élémentaires d'un code informatique dans une structure logique particulière. Ces structures de données sont prévues pour être allouées en mémoire, c'est-à-dire qu'une zone mémoire dans une mémoire physique du système est réservée pour stocker chaque structure de données, lors du chargement, de l'installation et de l'exécution du code en mémoire par l'environnement d'exécution. Cette phase d'allocation des données en mémoire est plus particulièrement mise en oeuvre par un composant logiciel appelé gestionnaire de mémoire du système.
Un gestionnaire de mémoire est ainsi prévu pour gérer la ressource mémoire du système lors de l'exécution d'un programme, en allouant des zones de mémoire aux structures de données, en déplaçant éventuellement ces structures de données d'une zone mémoire vers une autre ou encore en effaçant les structures de données qui ne sont plus utilisées par le programme. La difficulté à prendre en compte lors du développement d'un gestionnaire de mémoire est de définir une stratégie en terme de placement de données en mémoire qui soit adaptée au mieux aux caractéristiques de la mémoire du système et aux données à placer en mémoire.
Le schéma actuellement respecté dans la plupart des systèmes informatiques est le suivant. On dispose d'une mémoire de travail de type RAM dans laquelle un programme s'exécute, en rendant persistant des données dans une mémoire persistante, typiquement un disque dur. Dans ce contexte où l'exécution des programmes s'effectue entièrement en RAM, le problème du placement des structures de données entre différents types de mémoire ne se pose pas.
Cependant, si l'on considère les systèmes embarqués, par exemple de type cartes à puce, la gestion du placement en mémoire doit être prise en compte. En effet, les systèmes embarqués, du fait de leur portabilité, sont contraints en mémoire et, en particulier, disposent de très faibles capacités en mémoire vive de type RAM. Aussi, dans les systèmes embarqués, la RAM ne peut être utilisée seule en tant que mémoire de travail par les applications du système, comme cela est le cas par exemple dans les PC (Personal computer) où la capacité en mémoire RAM est normalement suffisante pour supporter la plupart des applications.
Les systèmes embarqués comprennent alors plusieurs types de ressources mémoires, qui présentent des propriétés différentes. Typiquement, ces systèmes embarquent de la mémoire morte de type ROM, qui ne peut être écrite qu'une seule fois et dans laquelle des instructions et des données préenregistrées sont accessibles seulement en lecture, de la mémoire non volatile de type EEPROM ou Flash EEPROM, dans laquelle des données peuvent être lues et écrites, et de la mémoire vive de type RAM.
Ces mémoires ne sont pas égales tant du point de vue des performances, que de la taille qu'elles occupent ou encore de leur mode d'accès. L'hétérogénéité des mémoires du système impliquent par conséquent des décisions à prendre quant au placement des structures de données en mémoire plus complexes de la part du gestionnaire de mémoire embarqué du système.
Par ailleurs, la ROM étant une mémoire à lecture seule, elle ne peut être programmée qu'une seule fois durant la phase de configuration du système. Notamment, une image mémoire du programme à charger dans la ROM est produite hors-carte sous forme d'un fichier écrit en langage C, appelé rom.c, par l'intermédiaire d'un outil logiciel appelé romizer, contenant les structures de données du code à charger dans la ROM lors de son initialisation. De plus, ce fichier indique où les structures de données doivent être placées dans les différentes mémoires disponibles (RAM, ROM, EEPROM...) par le gestionnaire de mémoire embarqué du système, au démarrage de celui-ci lors de l'exécution du code en ROM.
Cette phase de romization implémentée par le romizer, permet donc de définir quelles seront les structures de données à graver en ROM, et de déclarer quelles structures de données seront à placer dans l'une ou l'autre des mémoires disponibles lors du démarrage à l'exécution du code dans la ROM. Il est à noter que cette phase est basée sur une description du système tel qu'il était au moment où la romization a été effectuée.
Que ce soit le romizer ou le gestionnaire de mémoire, ces deux composants logiciels sont donc tous deux amenés à faire de la gestion mémoire et plus particulièrement, à appliquer des règles de placement des structures de données entre les différentes mémoires du système, l'ensemble de ces règles constituant alors une politique de placement des structures de données en mémoire.
Ces règles sont en fait écrites dans le code d'implémentation du romizer et du gestionnaire de mémoire. Elles ne sont donc pas exprimées en tant que telles, mais découlent plutôt des besoins explicites du programmeur, qu'il traduit dans le code logiciel du gestionnaire de mémoire ou du romizer selon une stratégie considérée comme étant optimale.
Or, la politique de placement des structures de données en mémoire dans un système est susceptible d'évoluer au cours du cycle de vie du système, par exemple en vue d'adapter une meilleure stratégie.
Egalement, dans n'importe quel système informatique, l'utilisation de la mémoire n'est pas la même selon l'application visée. Cela est d'autant plus vrai dans les systèmes embarqués, car les applications mises en place sur ces systèmes sont typiquement dédiées à un usage plus ou moins particulier. Ainsi, 2883390 5 certaines applications peuvent nécessiter d'allouer plus ou moins de structures de données et donc impliquent des règles spécifiques de placement de leurs structures de données en mémoire, qui peuvent alors ne pas être supportées par le gestionnaire de mémoire du système tel qu'il a été implémenté.
Par ailleurs, les règles de placement en mémoire telles que définies dans le code du romizer ou du gestionnaire de mémoire ne sont pas adaptables à tous les types de microcontrôleur et il est nécessaire d'adapter ces règles en fonction d'un microcontrôleur donné, dont la configuration mémoire fait que de nouvelles mises en correspondance des structures de données en mémoire doivent être appliquées, suivant que par exemple ces structures sont accédées souvent ou non en écriture ou en lecture.
On a donc plusieurs facteurs d'évolution des règles de placement des structures de données en mémoire. Soit, on trouve une meilleure stratégie pour les définir, soit ces règles doivent s'adapter en fonction des applications qui tournent sur le système, soit on cherche à les adapter à un nouveau type de microcontrôleur.
Si les règles de placement d'une structure de données en mémoire évoluent, il devient alors nécessaire de revoir et d'adapter le programme du composant logiciel concerné par la gestion de ces structures de données en mémoire. Or, actuellement, il n'existe aucun autre moyen que de réécrire à la main le programme de ce composant, puis de le tester à nouveau pour qu'il corresponde aux nouvelles règles de placement des structures de données en mémoire. Bien que cette opération est complexe et laborieuse, aucune technique n'a encore été développée visant à s'affranchir d'une telle étape de réécriture du code d'un gestionnaire de mémoire, à chaque fois que ce dernier doit s'adapter à des changements des règles de placement en mémoire des structures de données. Ce besoin ne s'est même jamais manifesté.
En effet, comme on l'a vu, dans le contexte des systèmes informatiques où l'exécution des programmes s'effectue entièrement en RAM, le problème du placement des structures de données en mémoire ne se pose pas.
Par ailleurs, concernant le monde de l'embarqué, jusqu'alors, on imposait des spécifications décrivant des règles générales de placement en mémoire très simples, que les développeurs d'applications embarquées devaient alors s'efforcer de suivre. C'est donc aux applications de s'adapter à la gestion de la configuration mémoire du système plutôt que l'inverse.
Dans ce contexte, le fait. de réécrire le code du gestionnaire de mémoire est considéré comme la façon la plus simple d'adapter ce dernier à d'éventuelles évolutions des règles de placement des données en mémoire.
L'invention vise justement à proposer un procédé permettant d'adapter, sans qu'il soit nécessaire de le réécrire à la main, le programme d'un gestionnaire de mémoire d'un système informatique à de nouvelles règles de placement des structures de données entre les différentes mémoires du système, ou entre différentes zones prédéfinies d'une mémoire du système, de sorte que la gestion de la mémoire du système puisse être configurable très simplement en fonction d'éventuelles évolutions de la politique de placement des structures de données en mémoire.
L'invention a ainsi pour objet un procédé de gestion du placement de structures de données en mémoire dans un système informatique, caractérisé en ce qu'il comprend une étape de déclaration d'un ensemble de règles de placement desdites structures de données en mémoire par l'intermédiaire d'un langage de programmation dédié à cet effet.
De préférence, le langage de programmation dédié est un langage déclaratif, basé sur le langage XML.
Selon un mode de réalisation, le procédé selon l'invention comprend la génération d'au moins une partie du code d'implémentation d'un gestionnaire de mémoire du système à partir de l'ensemble de règles de placement déclarées en langage de programmation dédié.
Selon un autre mode de réalisation, ledit ensemble de règles déclarées en langage de programmation dédié est utilisé pour configurer au moins une partie d'un gestionnaire de mémoire du système.
Avantageusement, la configuration du gestionnaire de mémoire consiste à faire coopérer ledit gestionnaire de mémoire avec un fichier de configuration comprenant une version interprétable par ledit gestionnaire de mémoire des règles de placement déclarées en langage de programmation dédié.
Selon un autre mode de réalisation, ledit ensemble de règles déclarées en langage de programmation dédié est utilisé pour générer des moyens de détermination du placement de structures de données en mémoire, aptes à coopérer avec un gestionnaire de mémoire du système pour recevoir de ce dernier une demande de détermination de placement d'une structure de données en mémoire et pour calculer ledit placement en fonction de ladite structure de données et desdites règles.
L'invention concerne encore un appareil électronique portable, doté de moyens de traitement de données comprenant un microprocesseur et des mémoires, caractérisé en ce qu'il comprend un gestionnaire de mémoire configurable et un fichier de configuration dudit gestionnaire de mémoire, ledit fichier comprenant une version interprétable par ledit gestionnaire de mémoire d'un ensemble de règles de placement de structures de données en mémoire déclarées dans un langage de programmation dédié à cet effet.
De préférence, cet appareil est une carte à puce.
Dans le contexte de l'invention et dans la description qui suit, le terme gestionnaire de mémoire doit être compris dans son acceptation générique et vise en fait tout composant logiciel apte à s'occuper de la gestion de structures de données en mémoire, qui agit soit à l'exécution d'un programme (type allocateur, ramasse-miettes...), soit en amont lors de la configuration du système (type romizer).
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles: - la figure 1 illustre l'utilisation d'un fichier de déclaration de règles de placement en langage dédié selon l'invention, pour la génération d'un code d'implémentation adapté d'un gestionnaire de mémoire du système; - la figure 2 illustre un mode de réalisation selon lequel une version interprétable du fichier de déclaration est installé sur une carte à puce en vue de la configuration du gestionnaire de mémoire du système.
La présente invention repose sur la conception d'un langage DSL (abréviation pour Domain Specific Langage ) pour définir une politique de placement des structures de données en mémoire. Dans le contexte de l'invention, l'approche DSL vise donc à proposer un langage de programmation dédié à cet effet.
Le langage dédié selon l'invention est un langage déclaratif, qui repose par exemple sur le langage XML (extensible Markup Language). Il est alors utilisé pour exprimer en tant que telles un ensemble de règles de placement de structures de données en mémoire, qui sont avantageusement indépendantes du code dans lequel le gestionnaire de mémoire du système est écrit. Ces règles pourront être exprimées très facilement dans la mesure où le langage informatique sur lequel est basée l'invention est justement dédié à l'expression de telles règles.
Ces règles zones mémoires concernant les taille, etc.) particulières liées aux applications du système.
pourront être exprimées en fonction de prédéfinies, de propriétés complexes structures de données à placer (type, ou encore en fonction d'exigences Il est donc possible de décrire facilement, via des fichiers XML, des règles de gestion de placement en mémoire et de constituer ainsi à partir de chaque description une bibliothèque de règles définissant une politique de placement globale des structures de données en mémoire pour le système.
Un exemple de règle décrite selon le principe de l'invention est présenté ci-dessous, concernant le placement initial d'une structure de données dans un contexte de programmation en langage orienté objet: < rule placeIn="EEPROM"> <instanceOf> <class className="MyClassl" /> </instanceOf> <links> <link type="fieldLink"> < modificators> <modificator name="static" /> <modificator name="final" /> </modificators> < /link> <link type="fieldLink" <variableNames> < variableName variableName="MyField" /> </variableNames> < /link> < /links> </rule> la règle ci-dessus indique ainsi que tous les champs de la classe MyClassl qui sont déclarés static 20 25 30 final et que le champ MyField de la même classe doivent être placés en EEPROM par le gestionnaire de mémoire, de type romizer dans cet exemple.
Un autre exemple où la gestion du placement de structures de données en mémoire peut être définie selon les principes de l'invention concerne le processus dit de ramasse-miette, qui a pour objet de récupérer de la mémoire dans la RAM en parcourant la mémoire pour identifier quelles sont les structures de données à conserver et à supprimer.
Ainsi, la déclaration en langage dédié selon l'invention d'une règle typique de déplacement durant le processus de ramasse-miette est donnée ci-dessous. Elle indique qu'un objet en RAM de type StringBuffer de taille entre 10 et 15 octets sera déplacée vers l'EEPROM si la RAM est au minimum aux trois quarts pleine mais que l'EEPROM n'est occupée qu'à 50%.
<rule memory="RAM"> <instanceOf> <classname=" StringBuffer"/> </instanceOf> <objectSize min="10" max="15"/> <memoriesUsage> <memoryUsage name="RAM" usedMin="75" usedMax="100"/> <memoryUsage name="EEPROM" usedMin="O" usedMax="50"/> </memoriesUsage> <destinationMem name="EEPROM"/> </rule> De telles règles de placement en langage dédié selon l'invention pourront donc être définies et adaptées très facilement et pourront ainsi être examinées par le ramasse-miette pour le rendre plus performant, voire pourront être utilisées pour générer le ramasse-miettes.
Si les exemples donnés ci-dessus concernent davantage la déclaration de règles de placement en mémoire pour la gestion mémoire dans le monde de l'embarqué, l'invention peut néanmoins être avantageusement appliquée à la gestion mémoire dans les systèmes informatiques non embarqués, comprenant une mémoire de travail unique d.e type RAM dans laquelle le programme s'exécute. Notamment, des règles de placement de structures de données en mémoire peuvent être déclarées en utilisant le langage dédié selon l'invention, dans le but d.e définir une politique de gestion du placement entre prédéfinies de la RAM.
Par exemple, on peut définir le ramasse-miettes ne doit pas minimiser le temps de parcours ramasse-miettes. Dans ce cas, différentes zones une zone de la RAM où intervenir de façon à de la mémoire par le on peut déclarer une règle selon laquelle les structures de données qui sont utilisées par le programme pendant toute sa durée d'exécution, devront être allouées dans ladite zone de la RAM où le ramasse-miettes n'intervient pas.
La déclaration de règles selon l'invention permet donc d'optimiser le fonctionnement du gestionnaire de 30 mémoire du système, en l'adaptant à la politique de placement définie par la déclaration des règles en langage dédié.
Comme illustré en figure 1, le langage dédié DSL est en effet utilisé pour générer un code d'implémentation adapté du gestionnaire de mémoire et du romizer, ou au moins une partie de ce code.
Plus précisément, un fichier de déclaration 10, dans lequel sont déclarées les règles de placement des structures de données en mémoire en langage DSL, est fourni en entrée à un module logiciel 20, qui va utiliser la représentation en langage déclaratif des règles de placement fournies par le fichier 10, pour générer le code 30, ou une partie de ce code, du gestionnaire de mémoire ou du romizer, ce code pouvant être exprimé suivant les besoins en langage C, java, etc. Pour ce faire, le module logiciel 20 de génération est pourvu de toute la logique fonctionnelle lui permettant, à partir d'une règle définie dans le fichier de déclaration, de déduire le comportement que doit avoir le programme du gestionnaire de mémoire à l'exécution. Ce comportement est alors traduit par des moyens spécifiques en C, Java ou autre.
Grâce au langage DSL mis en oeuvre par l'invention dédié à la déclaration de règles de placement en mémoire, le module logiciel 20 génère exactement le programme qui correspond à la politique de placement définie.
Dans une variante, la déclaration d'un ensemble de règles de placement en mémoire selon l'invention peut être utilisée en vue de la configuration du gestionnaire de mémoire du système ou d'une partie au moins du gestionnaire de mémoire, l'autre partie pouvant par exemple avoir été générée comme expliqué précédemment.
La figure 2 illustre un tel mode de réalisation dans le cadre d'un système embarqué de type carte à puce 40, dotée de moyens de traitement de données 50 comprenant un microprocesseur et des mémoires.
Selon ce mode de réalisation, le gestionnaire de mémoire 60 du système se présente, au moins en partie, sous la forme d'un code générique prévu pour assurer la gestion mémoire du système, en coopération avec un fichier de configuration 70 installé dans la carte, comprenant une version interprétable par le gestionnaire de mémoire du fichier de déclaration des règles de placement en mémoire en langage dédié. Ainsi, chaque fois que le gestionnaire de mémoire aura à gérer le placement d'une structure de données en mémoire, il lira le fichier de configuration 70 pour déduire son comportement de l'interprétation des règles qui y sont déclarées.
Le fichier de configuration peut ainsi être avantageusement mis à jour dans la carte, afin de le faire évoluer pour adapter la politique de gestion du placement de données en mémoire sur carte.
Dans un autre variante, on utilise le DSL selon l'invention, dédié à la déclaration de règles de placement en mémoire, pour générer des moyens de détermination du placement de structures de données en mémoire, appelés placeur de mémoire. Le placeur de mémoire comprend une interface pour communiquer avec le gestionnaire de mémoire du système, lequel est prévu pour délèguer au placeur le calcul du placement en mémoire d'une structure de données via une fonction d'interrogation du placeur. Le placeur, généré conformément aux règles de placement définies par l'intermédiaire du langage dédié selon l'invention, prend donc en paramètre la structure de données concernée et indique alors au gestionnaire où placer la structure de données en mémoire en fonction de ladite structure et des règles prédéfinies.
Le fait de déclarer les règles de placement de structures de données en mémoire par l'intermédiaire d'un langage dédié permet donc d'avoir des règles indépendantes du code du gestionnaire de mémoire du système, ce qui est optimal en termes de gestion mémoire. De plus, les règles ne sont plus figées, mais peuvent être adaptées très facilement en fonction des applications, du microcontrôleur etc., pour définir une nouvelle politique de placement.
Claims (8)
1. Procédé de gestion du placement de structures de données en mémoire dans un système informatique, caractérisé en ce qu'il comprend une étape de déclaration (10) d'un ensemble de règles de placement desdites structures de données en mémoire par l'intermédiaire d'un langage de programmation dédié à cet effet.
2. Procédé selon la revendication 2, caractérisé en ce que le langage de programmation dédié est un langage déclaratif, basé sur le langage XML.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend la génération (20) d'au moins une partie du code d'implémentation (30) d'un gestionnaire de mémoire (60) du système à partir de l'ensemble de règles de placement déclarées en langage de programmation dédié.
4. Procédé selon l'une quelconque des
revendications 1 à 3, caractérisé en ce que ledit
ensemble de règles déclarées en langage de programmation dédié est utilisé pour configurer au moins une partie d'un gestionnaire de mémoire (60) du système.
5. Procédé selon la revendication 4, caractérisé en ce que la configuration du gestionnaire de mémoire (60) consiste à faire coopérer ledit gestionnaire de mémoire avec un fichier de configuration (70) comprenant une version interprétable par ledit gestionnaire de mémoire des règles de placement déclarées en langage de programmation dédié.
6. Procédé selon la revendication 1 ou 2, caractérisé en ce que ledit ensemble de règles déclarées en langage de programmation dédié est utilisé pour générer des moyens de détermination du placement de structures de données en mémoire, aptes à coopérer avec un gestionnaire de mémoire du système pour recevoir de ce dernier une demande de détermination de placement d'une structure de données en mémoire et pour calculer ledit placement en fonction de ladite structure de données et desdites règles.
7. Appareil électronique portable (40), doté de moyens de traitement (50) de données comprenant un microprocesseur et des mémoires, caractérisé en ce qu'il comprend un gestionnaire de mémoire (60) configurable et un fichier de configuration (70) dudit gestionnaire de mémoire, ledit fichier comprenant une version interprétable par ledit gestionnaire de mémoire d'un ensemble de règles de placement de structures de données en mémoire déclarées dans un langage de programmation dédié à cet effet.
8. Appareil selon la revendication 6, caractérisé en ce que cet appareil est une carte à puce.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0502561A FR2883390A1 (fr) | 2005-03-15 | 2005-03-15 | Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie |
| PCT/EP2006/060608 WO2006097433A1 (fr) | 2005-03-15 | 2006-03-09 | Gestion du placement de structure de donnees en memoire basee sur un langage de programmation dedie |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0502561A FR2883390A1 (fr) | 2005-03-15 | 2005-03-15 | Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2883390A1 true FR2883390A1 (fr) | 2006-09-22 |
Family
ID=35385842
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0502561A Pending FR2883390A1 (fr) | 2005-03-15 | 2005-03-15 | Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2883390A1 (fr) |
| WO (1) | WO2006097433A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0810522A2 (fr) * | 1996-05-30 | 1997-12-03 | Sun Microsystems, Inc. | Procédé et systeme de stockage des classes dans une mémoire morte |
| EP1313020A1 (fr) * | 2001-11-19 | 2003-05-21 | EM Microelectronic-Marin SA | Architecture d'un circuit intégré pour carte à puce et procédé d'allocation mémoire associé |
| US20040073763A1 (en) * | 2001-10-01 | 2004-04-15 | Benoit Dageville | Dynamic and automatic memory management |
| EP1492000A2 (fr) * | 2003-06-25 | 2004-12-29 | Hyfinity Limited | Système et méthodes associées pour assemblage de logiciel |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2267477C (fr) * | 1999-03-30 | 2003-10-14 | Object Technology International Inc. | Creation de fichiers d'image memoire |
| DE10104043A1 (de) * | 2000-02-23 | 2001-08-30 | Ibm | Die Schaffung der Möglichkeit, dass vorhandene Anwendungen andere Sprachen als ihre eingebauten Makrosprachen benutzen, ohne die vorhandene Anwendung zu ändern |
-
2005
- 2005-03-15 FR FR0502561A patent/FR2883390A1/fr active Pending
-
2006
- 2006-03-09 WO PCT/EP2006/060608 patent/WO2006097433A1/fr not_active Application Discontinuation
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0810522A2 (fr) * | 1996-05-30 | 1997-12-03 | Sun Microsystems, Inc. | Procédé et systeme de stockage des classes dans une mémoire morte |
| US20040073763A1 (en) * | 2001-10-01 | 2004-04-15 | Benoit Dageville | Dynamic and automatic memory management |
| EP1313020A1 (fr) * | 2001-11-19 | 2003-05-21 | EM Microelectronic-Marin SA | Architecture d'un circuit intégré pour carte à puce et procédé d'allocation mémoire associé |
| EP1492000A2 (fr) * | 2003-06-25 | 2004-12-29 | Hyfinity Limited | Système et méthodes associées pour assemblage de logiciel |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006097433A1 (fr) | 2006-09-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Scargall | Programming persistent memory: A comprehensive guide for developers | |
| US7440980B2 (en) | Computer file management system | |
| WO2015055074A1 (fr) | Procédé et dispositif pour dynamiquement charger et appeler un programme | |
| CN102279748A (zh) | 远程存储本地执行的软件使用方法、系统、服务器及客户端 | |
| US20070094673A1 (en) | Configuration of Isolated Extensions and Device Drivers | |
| Gilbert et al. | Pocket ISR: Virtual machines anywhere | |
| EP1782191A2 (fr) | Procede de chargement d"un logiciel en langage intermediaire oriente objet dans un appareil portatif | |
| FR2989801A1 (fr) | Procede de gestion securisee d'un espace memoire pour microcontroleur | |
| Dietrich et al. | Xcorpus–an executable corpus of java programs | |
| WO2006000531A1 (fr) | Procede de gestion d'une carte a puce multi-applicative | |
| WO2021211911A1 (fr) | Système d'exploitation en nuage à intelligence artificielle | |
| CN108846129B (zh) | 存储数据访问方法、装置及存储介质 | |
| JP2012530297A (ja) | ソフトウェアコンポーネント状態に対するアクセスコントロール | |
| US10474512B1 (en) | Inter-process intra-application communications | |
| FR2883390A1 (fr) | Gestion du placement de structure de donnees en memoire basee sur une langage de programmation dedie | |
| EP2530586B1 (fr) | Procédé de génération d'un logiciel | |
| US8346821B2 (en) | Orphan object tracking for objects having acquire-release semantics | |
| WO2006048378A1 (fr) | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif | |
| US20180143839A1 (en) | Conversion Tool for Moving from Block-Based Persistence to Byte-Based Persistence | |
| EP3411821B1 (fr) | Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus | |
| Porter et al. | Transactional system calls on Linux | |
| EP2131287A1 (fr) | Dispositif électronique de mise à disposition de services autoadaptatifs en fonction de la plateforme de l'équipement hôte avec lequel il est en liaison | |
| WO2021032919A1 (fr) | Récuperateur de données dans un dispositif électronique | |
| FR3125142A1 (fr) | Procédé de traitement de l’exécution d’une fonction d’un applet, et procédé de chargement correspondant | |
| Thomas | ExtendingRuby1. 9 |