Discussion :

[Djobird]

Bonjour, je ne savais pas trop où poser cette question, désolé si cela n'est pas la bonne place.
Donc j'étudie en ce moment le fonctionement d'un compilateur, plus précisement le fonctionement du tas.
D'après ce que j'ai compris, le tas doit être virtuellement séparé en une suite d'espaces mémoir ayant une taille de puissance de deux. Bon mais je dois avoeur ne pas comprendre l'intérêt de cette séparation, pourriez vous m'éclaircire sur ce point ?

[gorgonite]

pour remettre les choses au point :
+ quelles bases as-tu en théorie des langages ?
+ as-tu fait des interprètes ? des compilateurs vers VM ?
+ connais-tu suffisamment l'architecture pour laquelle tu veux faire un backend ?

le tas doit être virtuellement séparé en une suite d'espaces mémoire ayant une taille de puissance de deux

perso, j'ai vu dans le code d'une jvm que le tas était alloué à une taille donnée, puis on mettait des données dedans... et quand y a plus de place, on regarde si on est pas déjà à la taille maximale possible ou autorisée, et si ce n'est pas le cas, on double la taille du tas

c'est assez simple...

[InOCamlWeTrust]

Il faut savoir de quel tas tu parles : est-ce qu'il s'agit du tas automatique, dans le cas du C, de la mémoire allouée statiquement à la compilation, ou encore du tas dynamique ?

Si c'est le dernier cas, c'est-à-dire le tas tel que géré par malloc(), en C, ce n'est absolument pas une affaire de compilation. Il est vrai que certaines implantations de malloc(), notament le malloc() GNU, utilisent un principe de découpage de cases mémoires de taille de puissance de 2 uniquement pour les petits objets, mais ce n'est pas, et de loin, la seule solution.

[millie]

Il y a de vieilles implémentations (et peut être des récentes) de malloc qui utilise les appels systèmes brk/sbrk qui ne font que repousser la limite du tas selon ce que l'on demande.

Ensuite, à toi de gérer le déplacement comme tu le souhaites.

[InOCamlWeTrust]

Oui, tout à fait : mais le problème de sbrk() et brk() vient du fait qu'il s'agit d'une fonction très rigide. En utilisant mmap(), on peut rendre la mémoire au système plus facilement, alors qu'avec sbrk()... c'est beaucoup plus compliqué !

Les implantations un peu plus modernes sont faites à coups de mmap(), au moins en ce qui concerne l'allocation des gros blocs de mémoire, qui sont rendus immédiatement au système lors de l'invocation de free().

Dans la GLibC, il y a les fonctions mmalloc() et mfree() qui permettent, entre autres, d'organiser la mémoire en plusieurs tas séparés : ce sont des fonctions de plus haut niveau que malloc() et free(), mais portables uniquement sur GNU.

Cependant, une implantation efficace de malloc() et de free(), robuste, c'est au bas mot 3000 à 4000 lignes de code...

[millie]

Oui, tout à fait : mais le problème de sbrk() et brk() vient du fait qu'il s'agit d'une fonction très rigide. En utilisant mmap(), on peut rendre la mémoire au système plus facilement, alors qu'avec sbrk()... c'est beaucoup plus compliqué !

Les implantations un peu plus modernes sont faites à coups de mmap(), au moins en ce qui concerne l'allocation des gros blocs de mémoire, qui sont rendus immédiatement au système lors de l'invocation de free().

Dans la GLibC, il y a les fonctions mmalloc() et mfree() qui permettent, entre autres, d'organiser la mémoire en plusieurs tas séparés : ce sont des fonctions de plus haut niveau que malloc() et free(), mais portables uniquement sur GNU.

Cependant, une implantation efficace de malloc() et de free(), robuste, c'est au bas mot 3000 à 4000 lignes de code...

Ah oui, je me disais qu'il devait y avoir des implémentations mieux qu'avec brk/sbk étant donné qu'il n'était pas possible de faire revenir le tas en arrière (donc il n'y avait aucune libération de mémoire réelle jusqu'à la fin du processus).

En plus, j'aurais dû le savoir, je l'avais déjà utilisé avec shm_open pour partager une zone mémoire entre deux programmes

[InOCamlWeTrust]

Certaines implantations de brk() sont faites de façon à faire diminuer le segment de données en cas d'argument négatif... mais je ne sais absolument pas si c'est standard, étant donné que ce sont des fonctions POSIX (si je me souviens bien...). En tous cas, cette "fonctionnalité" de brk() serait très difficile à exploiter, essentiellement du fait que les données à libérer et les blocs mémoire à rendre au système ne sont pas nécessairement en fin de segment.

Cependant, les systèmes évoluant, on peut faire de très bonnes implantations de malloc(), beaucoup plus rapides que le malloc() et free() GNU (j'en ai fait une qui était bien avancée et reposait sur un système entièrement différent), construites autour de la seule fonction sbrk() : les pages allouées et inutilisées par le programme ne seront, de toute façon, jamais réellement allouées par le système. Linux se comporte ainsi, par exemple.

Comme quoi, aujourd'hui, on peut se concentrer uniquement sur les performances en termes de temps de calcul et délaisser l'optimisation de l'utilisation de la mémoire (mais tout de même pas trop, hein !), chose inconcevable il y a quelques années encore.

[souviron34]

ben disons que ça dépend des cas de figure....

Si tu as une appli tournant 24/24 et demandant 10 megs/h, va bien falloir que tu t'en occupes quand même...

Sinon pour la remarque sur Linux pas complètement faux, mais pas complètement vrai non plus.. Xemacs fait redescendre sa mémoire au fur et à mesure des fichiers ouverts ou fermés (sa mémoire totale VUE de l'extérieur par top par exemple).

Il est cependant vrai que Unix et Linux considère qu'elle appartient encore au processus.. Cependant, dans les cas comme Xemacs, elle devient de facto dispo pour les autres processus...