octobre
2012
Un article de bouye
Chris Bailey (IBM)
Je me demande qui a fait la sélection musicale qu’on entend avant le début des sessions… Ils ont en train de passer « Chanson d’amour » de Zazie ; je ne suis as sûr que l’audience ait bien compris le refrain où elle dit « ils dépensent notre argent à sauver les banques »… Lol…
Ici aussi la salle est pleine, le sujet est porteur.
> Gestion de la mémoire
JVM = process comme un autre
32 bit = 4Go max dont une partie réservée pour l’OS + artie reservée par la JVM + le tas (heap) + tas natif (native heap = sockets, etc.)
64 bit = quelques hexaoctets
> Sur le tas natif on trouve tous les objets natifs : sockets, threads natives, etc.
> Surcharge introduite par l’usage des objets
int = 32bits
Integer = 4 fois plus gros sur 32 bit
Integer = Pointeur vers le type de classe (Integer), Flags (shape, hashcode), Lock, Value
Les tableaux contiennent aussi un champs contenant la taille
Sur 64 bit, un Integer est 7 fois plus gros qu’un int !!! Type, flag et lock sont sur 64 bit sauf si le type est compressé.
En utilisant des références compressées on peut réduire la taille du tas. Le tas natif n’est pas compressible par contre.
> Coût de la délégation
Lorsqu’on utilise des String, on crée en fait 2 objets : la String et un char[].
> Coût des collection
Les collections les plus évoluées ou les plus récentes sont plus efficaces mais consomment aussi plus de mémoire. Il faut donc faire attention à ce qu’on choisi en fonction de son usage
HashSet > Hashwmap > Hashtable > LinkedList > ArrayList > StringBuffer
Chaque entrée dans HashMap ou Hashtable rajoute 32o d’usage mémoire.
Une entrée de LinkedList fait 24o
Une entrée dans une ArrayList fait 4o. Une liste vide fait 88o.
StringBuffer fait 72o vide.
> Choix des collections
En général, les programmeurs choisissent leur collection par habitude et non pas par besoin.
Attention à prendre en compte l’espace mémoire inutilisé dans certaines collections : StringBuffer, ArrayList ont des tableaux qui peuvent être de plus grande capacité que leur contenu.
!!!! Souvent des applications mêmes simples utilisent un grand nombre de collections.
> Analyse
-> Eclipse Memory Analyzer Tool (existe aussi en version IBM)
L’analyse peut montrer qu’il y a beaucoup d’espace libre perdu dans les collections.
-> faire des lazy allocations pour éviter de créer des collections tan que rien n’est stocké dedans.
-> Pas de collection juste pour contenir un seul objet.
-> Choisir la bonne taille dès le départ.
-> Éviter de faire grossir la collection
-> Les collection ne libèrent pas la mémoire quand on retire des objets, mieux vaut réallouer à la nouvelle taille, recopier les données et jeter l’ancienne.
Il vaut mieux commencer à optimiser assez tôt.
Les collections d’Apache sont assez performantes et bien faites. Il faudrait faire un nettoyage complet des collections de l’API car leur design est assez ancien.
Au niveau usage / performance, TreeMap se situe entre LinkedList et les map.
Il faut utiliser un flag de la JVM pour activer les références compressées. Chez IBM ça devrait être activé par défaut et chez Oracle pas encore car ils veulent laisser le temps de bien le tester.
Lors d’un port 32 -> 64 bit, mieux vaut rester en JVM 32 si possible et sinon, prévoir plus de RAM (environ 50% plus).
1 Commentaire + Ajouter un commentaire
Commentaires récents
- dans Back from the future…
- dans Back from the future…
- dans Static linking = does not Compute
- dans Paquetage x 2
- dans Why you little…
[…] JavaOne, JavaOne 2012 From Java Code to Java Heap: Understandingthe Memory Usage of your Application par bouye (03/10/2012 18:13) Chris Bailey (IBM) Je me demande qui a fait la sélection musicale […]