Discussion :

[Shivan]

Bonjour,

Quelques questions concernant la heap et la stack

La heap : Espace mémoire dans lequelle sont instancié les objets java

La stack : une pile (donc LIFO) ou sont stockées les appels de méthodes et les variables locals au méthode ansi que les variables primitives.

A partir du JDK 6 il y a une option "escape analysis" qui permet de mettre sur la stack les variables dont le contexte reste "interne" à la méthode.

Je ne comprends pas assez bien le mécansisme sous-jacent pour expliquer le gain de performance. Les variables sur la stack occupe bien un espace mémoire, il faut les créer et les détruire au même titre que celles sur la heap. Je me trompe ?

Merci pour vos lumiéres

[adiGuba]

Salut,


Quelques exemples :

• Cela limite le nombre d'allocation/libération de mémoire, ce qui a un coût. En effet les données du stack sont alloué d'un bloc à l'entré de la méthode, puis libéré d'un bloc à sa sortie.
  
  En Java ceci est relativement moins important car le GC réserve lui-aussi la mémoire par bloc, et que l'instanciation d'un objet est moins onéreuse que l'allocation dynamique dans un langage natif, car cela n'implique pas forcément d'allocation/libération de mémoire auprès du système hôte.
  
  
• Cela limite la durée d'utilisation de la mémoire, puisque l'objet est immédiatement libéré à la fin de la méthode.
  
  En C/C++ par exemple cela offre une plus grande simplicité d'utilisation (on ne risque pas les fuites mémoires).
  En Java cela permet surtout de décharger le GC de son travail : les objets instanciés dans le heap ne seront pas traité par le GC !
  
  
• Les objets dans le stack ne peuvent pas être partagé entre plusieurs threads.
  
  Grâce à cela les processeurs peuvent optimiser l'accès aux données grâce à des instructions spécifiques...
  
  
• Pour les mêmes raisons la synchronisation éventuelle de l'objet en devient complètement inutile, et peut être carrément ignoré par la JVM...

a++

[Shivan]

Merci adiGuba pour tes réponses. C'est beaucoup plus clair.

En regardant ta signature je vois que tu as fait un billet (http://blog.developpez.com/adiguba/p...cape-analysis/) sur la fonction "escape analysis". Très intéressant d'ailleurs.

Une dernière question (concernant ton article) :

la pile n'est utilisée que pour stocker les types primitifs et les références des paramètres et variables locales d'une méthode.

Donc les paramétrés et variables locales sont alloués dans la heap et seul les références sont dans la stack. Ne pourrait t-on pas les allouer directement dans la stack ?

[Baptiste Wicht]

Donc les paramétrés et variables locales sont alloués dans la heap et seul les références sont dans la stack. Ne pourrait t-on pas les allouer directement dans la stack ?

C'est justement ce qui est fait avec "escape analysis" Ce sera en standard sur Java 7.

[Shivan]

merci Baptiste Wicht

Allez encore une question... pourquoi on n'a pas utiliser la stack plus tôt pour ces cas de figure. y avait t-il un intérêt initial à utilisé la heap ?

[adiGuba]

En langage natif l'utilisation du stack induit une allocation mémoire bien différente de l'allocation dynamique qui se retrouve dans le code source. De même cela implique un passage des objets par copie (puisque la mémoire est libéré à la fin de la méthode).

En Java l'allocation des objets est basé sur le modèle dynamique, couplé à un GC, et les objets sont passé par références (ce qui évites les copies inutiles).


De ce fait l'utilisation du stack pour les objets est un peu plus complexe, et nécessite certaines conditions et traitements particulier lors de l'exécution...

a++

[Shivan]

Ok tout est clair pour moi.

Merci à vous 2 pour vos réponses