FR 2899353 A1 20071005 FR 0602849 A 20060331 - 1 " Système de gestion mémoire pour la réduction de la fragmentation mémoire." La présente invention se rapporte à un système de gestion mémoire d'un processus élaboré en langage C/C++ dans une unité de traitement. Elle trouve une application particulièrement intéressante dans des programmes ou applications informatiques à exécution de longue durée ("long-running application") telles que des applications serveurs. Ces applications doivent io maintenir l'utilisation de leur mémoire stable dans le temps. D'une façon générale, il existe deux types d'utilisation de mémoire : - la quantité de mémoire réellement utilisée par le processus, appelé "heap usage" qui doit être stable, sinon le processus risque de rencontrer des problèmes de mémoire. 15 - la quantité de mémoire réservée par le système d'exploitation pour le processus, appelé "virtual memory usage". Elle comprend le "heap usage" aussi bien que les bibliothèques et le code de l'application. La fragmentation de mémoire est la différence entre l'utilisation de mémoire virtuelle et l'utilisation de pile ("heap usage). C'est la mémoire 20 réservée par le système et elle ne contient rien d'utile pour le processus. Elle ne peut pas être nulle, mais doit être maintenue aussi bas que possible. Si la fragmentation de mémoire continue à augmenter, de sérieux problèmes peuvent subvenir : - à mesure que la mémoire virtuelle augmente, cela met plus de 25 pression sur le système d'exploitation et dégrade l'ensemble des performances, parfois par un facteur très significatif; pour des applications fonctionnant en 32 bits, la quantité de mémoire virtuelle disponible est limitée à 4 gigaoctets ou moins, selon la plateforme utilisée. Une telle application manquerait par la suite de mémoire 30 virtuelle et s'interromprait. Quelques langages de programmation, tels que le Java ou .NET, résout le problème de fragmentation de mémoire en déplaçant des objets dans la mémoire, ainsi ils peuvent "compacter" la pile ("heap"). Cette solution n'est pas possible avec les applications C ou C++, où les 35 objets ont une adresse fixe dans la mémoire jusqu'à ce qu'ils soient libérés. 2899353 - 2- Les allocateurs C/C++ existants ont notamment un ou plusieurs des faiblesses suivantes : : - l'allocateur de mémoire par défaut peut ne pas mettre en oeuvre correctement la fragmentation interne en raison d'un algorithme 5 d'assemblage de bloc inadéquat. Si les classes de taille contrôlées par l'allocateur ne conviennent pas aux tailles utilisées par le processus, ceci augmentera la fragmentation interne. - il peut également ne pas mettre en oeuvre correctement la fragmentation externe en utilisant faible algorithme d'assemblage, io "coalescing algorithm" en langue anglaise. L'assemblage de blocs libres est généralement très consommatrice, mais c'est une étape obligatoire afin de limiter la fragmentation externe. Un des problèmes techniques est donc le fait que la fragmentation consomme du temps et des ressources, ce qui pénalise à terme d'autres 15 applications du système. La présente invention a pour but de remédier aux inconvénients précités en proposant un nouveau allocateur de mémoire de basse fragmentation pour le C/C++. L'invention a pour but de remplacer l'allocateur de mémoire par défaut fourni avec le système d'exploitation et d'éviter la 20 fragmentation externe. L'invention a encore pour but de maintenir la mémoire virtuelle aussi faible que possible. On atteint au moins l'un des objectifs précités avec un système de gestion mémoire d'un processus élaboré en langage C/C++ dans une unité 25 de traitement, ce système comprenant : - un allocateur apte à allouer des espaces mémoires pour des objets utilisés par le processus et à libérer des espaces mémoires non utilisés par le processus vers le système d'exploitation de l'unité de traitement; - un mécanisme asynchrone apte à définir une zone tampon 3o constituée d'un ensemble de blocs mémoires disponibles pour le processus, tous les blocs mémoires dudit mécanisme étant de même taille égale à m*32Ko, avec m compris entre 1 et 4; - chaque bloc mémoire de m*32Ko, en provenance dudit mécanisme et utilisé par le processus, est géré sous forme de régions 35 mémoire selon la technique de gestion de mémoire "chunk" par l'allocateur; 2899353 - 3- pour de grands objets ("large object" en anglais) dont la taille est comprise dans une plage de tailles prédéterminée, chaque bloc mémoire de m*32Ko est considéré comme un chunk multi-tailles renfermant plusieurs desdits grands objets de différentes tailles, ledit chunk multi-tailles comportant une 5 en-tête indiquant qu'il s'agit d'un chunk renfermant de grands objets, un champ de bits ou "bit fields", et une zone de données comprenant des petits blocs mémoire en cours d'utilisation et de petits blocs mémoires libres, les petits blocs mémoire du chunk multi-tailles étant tous de même taille; l'allocateur comprenant des moyens de mise en oeuvre de l'algorithme de Bruijn en combinaison avec la technique de champ de bits pour déterminer des blocs adjacents libres lors de la libération d'un petit bloc mémoire par le processus. Plus précisément, lorsqu'un petit bloc mémoire est libéré par le processus, l'allocateur recherche s'il existe des petits blocs libres adjacents de façon à les assembler ("coalescing") et constituer ainsi un plus gros bloc à libérer. L'algorithme de Bruijn, que l'on peut trouver dans le document "Using de Bruijn Sequences to Index a 1 in a Computer Word", Charles E. Leiserson, Harald Prokop, Keith H. Randall, MIT Laboratory for Computer Science, Cambridge, MA 02139 USA, )uly 7, 1998 , intervient dans la recherche de blocs adjacents libres en combinaison avec le champ de bits. Cette technique permet d'accélérer la recherche et donc de libérer rapidement de la mémoire vers le système d'exploitation tout en limitant la fragmentation. La présente invention apporte bien une réponse technique à un problème technique. Les dits grands objets ont une taille inférieure à m*32Ko (kilo-octets). Avec le système selon l'invention, l'allocateur réserve seulement de faibles plages de mémoire et ces plages sont rendues au système lorsqu'elles deviennent vides. Ainsi, on garde la mémoire virtuelle du processus aussi bas que possible. Au contraire, dans les systèmes de l'art antérieur, les allocateurs réservent une plage étendue d'espace adresse et contrôlent leurs blocs mémoires dans cette plage. Cette plage d'espace adresse ("heap"), selon l'art antérieur, se développe si nécessaire; l'inconvénient étant le fait que la mémoire n'est jamais renvoyée vers le système, l'utilisation de la mémoire virtuelle du processus pouvant ainsi augmenter, ceci augmentant la pression mémoire du côté système. 2899353 ù 4 Dans le système selon la présente invention, le mécanisme asynchrone, appelé "free store", constitue une zone tampon dans laquelle on garde à disposition de l'allocateur un ensemble de blocs mémoire. Le nombre de ces blocs varie entre une valeur min et une valeur max. Plus précisément, 5 le mécanisme asynchrone comprend des moyens pour réserver un bloc mémoire de m*32Ko lorsqu'un seuil minimum du nombre de blocs mémoire est dépassé, et des moyens pour libérer vers le système d'exploitation des blocs mémoire de m*32Ko lorsqu'un seuil maximum du nombre de blocs mémoire est dépassé. 10 La présente invention est notamment remarquable par le fait que le mécanisme asynchrone réserve de la mémoire par bloc mémoire de m*32Ko, m peut être avantageusement égale à 2. On alloue au processus de la mémoire par bloc mémoire de 64Ko. Ainsi, en travaillant avec des blocs mémoire de 64Ko par exemple, on utilise peu de mémoire virtuelle et 15 l'allocateur peut gérer ces blocs mémoire de manière plus rapide. La taille de bloc mémoire peut être paramétrée en fonction des contraintes du système d'exploitation et du type d'application. Par exemple, on peut utiliser 128Ko au lieu de 64Ko pour une application 64 bits. De préférence, chaque petit bloc mémoire présente une taille de 8 20 octets. Lorsqu'un objet ne présente pas une taille multiple de 8 octets, on arrondit la taille de l'objet à la taille multiple de 8 octets immédiatement supérieure. Selon une caractéristique avantageuse de l'invention, chaque petit bloc mémoire en cours d'utilisation par le processus comporte une zone 25 renfermant l'objet en cours d'utilisation et une en-tête indiquant la taille dudit objet en cours d'utilisation. Par ailleurs, chaque petit bloc mémoire libre peut comporter un lien vers le petit bloc mémoire libre précédent, un lien vers le petit bloc mémoire suivant, et un espace mémoire libre pour des données. 30 Le système selon l'invention comprend en outre une liste dite liste libre de grands objets, dans laquelle sont répertoriés, pour chaque taille de ladite plage de tailles prédéterminée, des liens vers des petits blocs mémoire libres dans des chunks multi-tailles. Selon une caractéristique avantageuse de l'invention, ladite plage de 35 tailles prédéterminée consiste en une plage telle que 256 octets Bien que l'invention n'y soit pas limitée, on va maintenant décrire un 25 système selon la présente invention pour un allocateur de type 32bits. L'homme du métier comprendra qu'il aisé d'étendre la présente solution à une application de type 64 bits, notamment en ajustant m dans la taille de bloc m*32Ko. Sur la figure 1, on voit un graphe comportant deux courbes. La courbe 30 inférieure représente l'utilisation de la pile "heap usage", et la courbe supérieure représente la mémoire virtuelle. L'écart entre les deux courbes est la fragmentation. Une façon de limiter la fragmentation est de réaliser l'assemblage ("coalescing" en anglais). Comme on peut le voir sur la figure 2, il s'agit de regrouper un bloc mémoire venant d'être libéré avec des blocs 35 mémoires libres adjacents. - 7 L'allocateur selon l'invention distingue trois types d'objets : les grands objets ("large objects"); les petits objets ("small objects") et les très grands objets ("huge objects"). Pour éviter la fragmentation d'espace adresse, un facteur important dans un processus de type 32 bits où l'espace adresse disponible est rare, on utilise des mémoires tampons à taille fixe (taille réglée à 64Ko). Pour allouer les très grands objets, on alloue des tampons mémoire plus grands (taille fixée à n x 64Ko). Ces mémoires tampons sont alloués en utilisant des primitives bas 10 niveau du système d'exploitation et doivent être alloués à des adresses multiples de 64Ko. Les tailles d'objet. La norme de C exige que l'adresse d'un objet soit alignée sur la limite d'un mot de 8octets. Cela signifie que l'allocateur peut arrondir la taille de 15 l'objet jusqu'à limite des 8 octets suivants, réduisant ainsi le nombre de "classes taille" à gérer. L'allocateur selon l'invention définit trois types d'objets selon les tailles suivantes : - petits objets taille 256 octets 20 grands objets : taille > 256 octets et taille limite (la limite est sensiblement égale à 63Ko) très grands objets ; taille > limite. Sur la figure 3 on voit schématiquement la façon dont différents applicatifs du système s'interfacent. Le mécanisme asynchrone est une zone 25 tampon qui délivre des blocs mémoires qui sont gérés par l'allocateur. Ce dernier reçoit des instructions du système d'exploitation et du processus pour allouer ou libérer des blocs mémoires. Les fonctions de l'allocateur. 30 L'allocateur fournit une interface comprenant deux fonctionnalités : allouer un objet : l'allocateur reçoit la taille de l'objet et doit renvoyer l'adresse de l'objet. Il arrondit la taille de l'objet jusqu'à la limite du bloc 8 octets supérieur. Il détermine alors si l'objet est petit, grand ou très grand et gère l'objet en conséquence. - 8 - Libérer un objet : l'allocateur reçoit l'adresse de l'objet. Pour obtenir la taille de l'objet à partir de l'adresse de l'objet, l'allocateur arrondit l'adresse de l'objet à la limité de la mémoire 64Ko précédent, et lit la valeur stockée à cette adresse arrondie. Cette valeur est un indice concernant la taille de l'objet : ^ si la valeur est zéro, il s'agit d'un grand objet, ^ si la valeur est 256, c'est un petit objet, ^ autrement, c'est un très grand objet. L'allocateur permet de rendre de la mémoire inutilisée vers le système 10 d'exploitation autant que possible, et de fusionner des blocs libres de manière très efficace en utilisant la technique de champ de bits et l'algorithme de Bruijn. Les fonctions du mécanisme asynchrone ("free store") : 15 Le "free store" ou réserve de mémoire est un mécanisme asynchrone (fonctionnant selon des routines propres) exécutant la gestion bas niveau de mémoire en utilisant les primitifs du système d'exploitation. Il maintient continuellement une liste de tampons mémoire 64Ko (plus que la taille minimum du "free store") pour satisfaire immédiatement aux besoins de 20 l'allocateur lorsque de nouveaux "page chunks" (régions mémoires fixes) ou un nouveau "chunk" (région fixe) pour de grands objets doivent être alloués. Réciproquement, il retarde la destruction des mémoires tampons 64Ko et la libération de page chunks vides jusqu'à ce que la taille maximum du "free store" soit atteinte. De cette façon, des opérations de mémoire de bas niveau 25 ont un impact minimum sur les performances de l'allocateur. Les routines du "free store" attendent un sémaphore devant être signalé par l'allocateur pour nettoyer des mémoires tampons lorsque la taille du "free store" est au-dessus de la taille maximum, et pour pré-allouer des mémoires tampons 64Ko lorsque la taille du "free store" est inférieure à la 30 taille minimum. Des mémoires tampons surdimensionnés sont alloués à chaque fois que cela est nécessaire, et sont détruits dès qu'ils sont libérés. Des mémoires tampons contenant des page chunks (pour de petits objets) sont détruites seulement lorsque tous les pages chunks sont déliés de 35 la mémoire et lorsque le page chunk de tête est vide. - 9 On va maintenant décrire la gestion de petits objets. En ce qui concerne la structure. Pour de petits objets, on doit limiter au maximum la charge mémoire. Pour ce faire, on utilise la technique des "page chunks" pour stocker de petits objets de la même classe de taille. Un "page chunk" est une zone mémoire comprenant une en-tête et une partie data. Pour les petits objets, la réserve de mémoire ou "free store" met à disposition de l'allocateur un bloc mémoire de 64Ko. Ce bloc mémoire est partitionné en une pluralité de page chunks lo comme on peut le voir sur la figure 4. En fonction de la plateforme (système d'exploitation) utilisé, un page chunk peut être de taille 4Ko ou 8Ko, on aura ainsi 16 ou 8 page chunks dans un bloc mémoire de 64Ko. Le premier page chunk du bloc mémoire est une en-tête globale ("head chunk") comportant une indication permettant à l'allocateur de détecter qu'il s'agit d'un bloc 15 mémoire pour petits objets. Comme on le voit sur la figure 4, chaque page chunk comporte une en-tête interne ("chunk header") dans laquelle on trouve des données relatives : - à la taille des objets présents dans le page chunk, - un adressage pages ("mapped pages"), 20 - le page chunk précédent et suivant, l'objet en cours, - l'objet libre, et - les objets alloués. La partie restante du page chunk est une partie de data comprenant 25 plusieurs petits blocs mémoires de même taille. Chaque petit bloc mémoire est libre ou renferme un objet. En ce qui concerne l'allocation d'un petit objet. L'allocateur contient une liste libre externe pour petits objets. Cette liste libre externe est représentée sur la figure 5. Cette liste comporte pour 30 chaque type de taille (dans la limite de la définition de petite taille, c'est à dire En ce qui concerne la libération d'objet. Etant donné l'adresse de l'objet, l'allocateur calcule l'adresse de début du bloc mémoire concerné en faisant : adresse de l'objet modulo 64Ko (puisque les blocs mémoire sont alignés sur les limites de mémoire 64Ko). La valeur à cette adresse, en cas de petit objet, est plus petite que 256 parce que c'est l'adresse du "head chunk", et le premier attribut stocké dans un page chunk est une taille d'objet, inférieure à 256. L'allocateur calcule l'adresse du page chunk contenant l'objet libéré : adresse objet modulo taille de page chunk. La taille d'objet est obtenue à partir de l'en-tête du page chunk. L'objet libéré est alors lié à la liste libre interne du page chunk, et le nombre d'objets est décrémenté. Si le page chunk devient vide, il est délié de la liste libre externe de petits objets et il retourne à la réserve de mémoire. La réserve de mémoire utilise un attribut spécifique dans le page chunk ("adressage pages" sur la figure 4) pour déterminer si tous les page chunks dans le bloc mémoire de 64Ko sont vides ou non-adressés. Auquel cas, l'ensemble du bloc mémoire peut être retourné vers le système d'exploitation. On va maintenant décrire la gestion de grands objets. En ce qui concerne la structure. Pour de grands objets, on utilise une seule région mémoire de taille fixe, dite chunk. En d'autres termes, chaque bloc mémoire 64Ko en provenance du "free store" est transformé en un seul chunk. Ce chunk peut contenir de grands objets de classes de taille différentes. On a donc besoin d'un mécanisme d'assemblage de petits blocs mémoire. Selon la présente - 11 invention, l'algorithme d'assemblage n'est pas basé sur des liens établis dans des listes ou des arbres binaires comme dans l'art antérieur, mais sur le champ de bits. Chaque chunk pour grands objets contient un champ de bits. Chaque bit dans ce champ donne l'état d'un bloc mémoire 8-octets : 0 si libre, 1 si utilisé. Ceci permet un assemblage efficace et rapide, sans balayage de listes comme dans l'art antérieur. Sur la figure 6 est représentée la structure d'un chunk 64Ko. Puisqu'un chunk pour grands objets mélange différentes classes de taille, la taille d'objet est stockée en en-tête de chaque grand objet alloué. Chaque petit bloc mémoire en cours d'utilisation comporte une en-tête et une partie data renfermant l'objet en cours d'utilisation. Chaque petit bloc mémoire libre comporte un lien vers un bloc libre précédent et un lien vers un bloc libre suivant, et une partie data non utilisée (libre). En ce qui concerne l'allocation d'objet. Comme les grands objets exigent une en-tête pour stocker leur taille, on ajoute la taille de l'en-tête à la taille de l'objet et on arrondit la taille de l'objet à I a limite du prochain bloc 8-octets. Une meilleure recherche de correspondance est exécutée sur une liste libre externe répertoriant pour chaque taille un éventuel lien vers un bloc mémoire de même taille disponible. La recherche démarre à partir de la taille de l'objet : - en cas de correspondance exacte, le bloc libre est délié de la liste libre et utilisé pour allouer l'objet, - si on trouve un bloc libre plus grand, ce bloc libre est délié et scindé. Le reste est lié à la liste libre correspondante, s'il n'y a aucun bloc libre de taille supérieure disponible, on crée un nouveau chunk pour grands objets en demandant une mémoire tampon 64Ko depuis la réserve de mémoire. Ce nouveau chunk contient un unique grand bloc libre, et le champ de bits est rempli de zéros. Ce grand bloc libre est scindé (à moins que la taille d'objet soit exactement (n - 1) x 8 octets) et le reste est lié à la liste libre correspondante. Lorsqu'un bloc mémoire a été trouvé, les bits correspondants dans le champ de bits sont tous placés à 1. 2899353 - 12 - Sur la figure 7 on voit un exemple d'allocation d'un objet de 264 octets. Pour la taille de 264 octets, la liste libre ne comprend aucun bloc libre. On se rabat alors sur la taille immédiatement supérieure de 272 octets. Là un bloc libre est disponible. On utilise donc ce bloc libre, et les 8 octets restants 5 constituent un bloc libre qui est lié à la suite des blocs libres de même taille. En ce qui concerne la libération. Lorsque l'allocateur libère un grand objet, il obtient d'abord la taille de l'objet depuis l'en-tête de l'objet et assemble ensuite ce nouveau bloc libre avec les blocs libres adjacents. Il utilise le champ de bits pour identifier ces lo blocs libres adjacents. Pour ce faire, on recherche le précédent ou le suivant bit à "1" dans le champ de bits en sautant des mots nuls. Une itération déplace le curseur en avant ou en arrière 32 x 8 = 256 octets dans la mémoire. Lorsqu'on trouve un mot non nul, le problème consiste à trouver le premier (ou dernier) bit à "1" dans ce mot. Pour cela, on utilise 15 avantageusement une méthode efficace et transférable : cette méthode utilise les séquences de De Bruijn pour indexer un "1" dans un mot informatique. Sur la figure 8 on voit une méthode d'assemblage de blocs mémoire libres. Le bloc mémoire libéré est entouré de deux blocs libres. On parcourt le 20 champ de bits pour trouver les blocs libres adjacents. On enlève ces blocs libres de la liste libre. On met à jour le champ de bits puis on lie, à la fin de la liste libre, le nouveau bloc mémoire formé de l'assemblage ou fusion des trois blocs libres. En fait, l'allocateur contient deux "free list" ou vecteur de listes 25 chaînées de bloc mémoire : une pour les petits objets (liste de "page chunks"), et une pour les grands objets (liste d'emplacements mémoire libres pour chaque taille d'objet). Ces vecteurs sont initialisés statiquement, au démarrage du processus utilisant l'allocateur. Avantageusement, les listes (une pour chaque élément du vecteur) sont chaînées dans les deux sens, afin 3o de permettre la suppression d'un chunk sans parcourir toute la liste. On va maintenant décrire la gestion de très grands objets. En ce qui concerne la structure. Un très grand objet est alloué depuis un chunk surdimensionné, 35 construit en utilisant un bloc mémoire surdimensionné, c'est à dire un bloc - 13 mémoire de taille supérieure à 64Ko. Il y a un chunk surdimensionné pour chaque très grand objet. Sur la figure 9 on voit un tel chunk avec une en-tête renfermant la taille de l'objet, une partie data renfermant l'objet et une partie data non utilisée à la fin du chunk surdimensionné. En ce qui concerne l'allocation d'objet. Pour un très grand objet, l'allocateur demande un bloc mémoire surdimensionné depuis la réserve de mémoire. De tels blocs mémoire ne sont pas pré-affectés. En ce qui concerne la libération de l'objet. Lorsque l'allocateur libère un très grand objet, le bloc mémoire surdimensionné est libéré, et on renseigne la réserve de mémoire de sorte que la mémoire retourne vers le système d'exploitation dès que possible. La présente invention concerne donc un système de gestion mémoire d'un processus élaboré en langage C/C++ dans une unité de traitement. Ce système comprend un allocateur qui traite des blocs mémoires de taille prédéterminée, par exemple 64Ko. On définit des grands objets comme étant des objets de taille comprise entre 256 et 64Ko. Pour de tels objets, chaque bloc mémoire 64Ko est considéré comme une région mémoire apte à recueillir plusieurs grands objets de tailles différentes. Lorsqu'un objet n'est plus utilisé par le processus, l'espace libéré est susceptible d'être renvoyé vers le système d'exploitation. Avant cela, on fusionne cetespace libre avec des espaces libres adjacents. Pour la recherche des espaces libres adjacents, on utilise l'algorithme des séquences de Bruijn appliqué au champ de bits disposé dans chaque région mémoire prédéterminée. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.30 REVENDICATIONS 1. Système de gestion mémoire d'un processus élaboré en langage C/C++ dans une unité de traitement, ce système comprenant Un allocateur apte à allouer des espaces mémoires pour des objets utilisés par le processus et à libérer des espaces mémoires non utilisés par le processus vers le système d'exploitation de l'unité de traitement; Un mécanisme asynchrone apte à définir une zone tampon constituée d'un ensemble de blocs mémoires disponibles pour le processus, tous les blocs mémoires dudit mécanisme étant de même taille égale à m*32Ko, avec m compris entre 1 et 4; Chaque bloc mémoire de m*32Ko, en provenance dudit mécanisme et utilisé par le processus, est géré sous forme de régions mémoire selon la technique de gestion de mémoire chunk par !'allocateur; pour de grands objets dont la taille est comprise dans une plage de tailles prédéterminée, chaque bloc mémoire de m*32Ko est considéré comme une région mémoire chunk multi-tailles renfermant plusieurs desdits grands objets de différentes tailles, ladite région mémoire chunk multi-tailles comportant une en-tête indiquant qu'il s'agit d'une région mémoire chunk renfermant de grands objets, un champ de bits ou "bit fields", et une zone de données comprenant des petits blocs mémoire en cours d'utilisation et de petits blocs mémoires libres, les petits blocs mémoire de la région mémoire chunk multi-tailles étant tous de même taille; l'allocateur comprenant des moyens de mise en oeuvre de l'algorithme de Bruijn en combinaison avec la technique de champ de bits pour déterminer des blocs adjacents libres lors de la libération d'un petit bloc mémoire par le processus. 2. Système selon la revendication 1, caractérisé en ce que le mécanisme asynchrone comprend des moyens pour réserver un bloc mémoire de m*32Ko lorsqu'un seuil minimum du nombre de blocs mémoire est dépassé, et des moyens pour libérer vers le système d'exploitation des blocs mémoire de m*32Ko lorsqu'un seuil maximum du nombre de blocs mémoire est dépassé. 3. Système selon la revendication 1 ou 2, caractérisé en ce que m est égale à 2. 5 4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque petit bloc mémoire présente une taille de 8 octets. 5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque petit bloc mémoire en cours d'utilisation par le processus comporte une zone renfermant l'objet en cours d'utilisation et une en-tête indiquant la taille dudit objet en cours d'utilisation. i0 6. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque petit bloc mémoire libre comporte un lien vers le petit bloc mémoire libre précédent, un lien vers le petit bloc mémoire suivant, et un espace mémoire libre pour des données. 15 7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une liste dite liste libre de grands objets, dans laquelle sont répertoriés, pour chaque taille de ladite plage de tailles prédéterminée, des liens vers des petits blocs mémoire libres dans des 20 régions mémoires chunks multi-tailles. 8. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite plage de tailles prédéterminée consiste en une plage telle que 256 octets 9. Système selon la revendication 8, caractérisé en ce que pour des petits objets dont la taille est inférieure ou égale à 256octets, chaque bloc mémoire de m*32Ko devant être utilisé est subdivisé en une pluralité de segments mémoires fixes dits page chunks ; chaque segment mémoire fixe 30 page chunk comportant une en-tête renfermant la taille des objets et une indication du caractère vide ou non du segment mémoire fixe page chunk , et plusieurs petits blocs mémoires de même taille, chaque petit bloc mémoire étant libre ou rempli d'objet. 10. Système selon la revendication 9, caractérisé en ce qu'il comprend en outre une première liste libre de petits objets associée à l'ensemble de segments mémoires fixes page chunks de telle sorte que pour chaque taille d'objet des liens vers des petits blocs mémoire libres sont établis, et en ce qu'il comprend en outre pour chaque segment mémoire fixe page chunk , une seconde liste libre interne de petits objets, cette liste libre interne comprenant des liens entre objets et petits blocs mémoires libres au sein d'un même segment mémoire fixe page chunk ; lesdites première et seconde listes libre de petits objets sont gérées par l'allocateur pour l'allocation et la libération de mémoire. 11. Système selon la revendication 9 ou 10, caractérisé en ce que pour libérer un objet, l'allocateur comprend des moyens pour réaliser l'opération adresse de l'objet à libérer modulo m*32Ko de façon à en déduire la taille dudit objet à libérer. 12. Système selon l'une quelconque des revendications 9 à 11, caractérisé en ce que l'allocateur comprend des moyens pour libérer un bloc mémoire de m*32Ko vers le système d'exploitation lorsque l'ensemble des segments mémoires fixes page chunks de ce bloc mémoire sont vides. 13. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que pour de très grands objets de tailles supérieures à m*32Ko, l'allocateur comprend des moyens pour prélever depuis le mécanisme asynchrone plusieurs blocs mémoire de taille m*32Ko chacun de façon à former une région mémoire chunk surdimensionnée, chaque région mémoire chunk surdimensionnée comportant une en-tête signalant qu'il s'agit d'une région mémoire chunk comportant un objet de très grande taille.30