Discussion :

[ToTo13]

Bonsoir,

je suis en pleine crise d'optimisation maximale de ma plateforme java, quitte à perdre les avantages du langage pour descendre au plus bas niveau.

Or je viens de lire cet article et il est marqué : "effets du ramasse-miette (Garbage Collector), très difficile à optimiser."

"Optimiser le ramasse miette", très bien mais comment ?
On m'avait parlé du fait de mettre systématiquement à null les pointeurs qui ne seront plus utiliser, mais je ne connais pas plus.

Est ce que quelqu'un aurait des précisions sur le sujet ?
Merci d'avance...

[CyberChouan]

Travailles-tu sur une application qui a réellement besoin de beaucoup de mémoire ou de performances ?

Dans le cas contraire, je te conseille de ne pas trop te préoccuper du ramasse-miettes mais plutôt de te concentrer sur ton code. Si ce dernier est bien écrit, le ramasse-miettes fait en général son travail correctement sans que tu aies à te soucier de l'optimiser.

Cette problématique du ramasse-miettes provient du fait qu'en Java, on ne gère pas explicitement la libération de mémoire : c'est la JVM qui s'en charge pour nous.

On peut cependant noter que Sun (Oracle maintenant) a beaucoup travaillé sur l'optimisation interne du ramasse-miettes (le "Garbage First").

Un lien qui pourrait t'intéresser : http://www.oracle.com/technetwork/ja...-5-138395.html

[ToTo13]

Les deux :-(
Je fais du traitement d'image (2000 x 1000, donc beaucoup de place en mémoire) et j'ai donc besoin d'avoir les meilleures performances (car beaucoup de traitement) avec la meilleure gestion mémoire (car beaucoup d'image en même temps, donc fort risque de swap).

Je vais jeter un coup d'oeil au lien que tu m'as donné, merci.

Mais c'est toujours pareil lorsque l'on dit "bien codé" ! Qu'est ce que cela signifie en java ?

[tchize_]

Si tu as des gros objet en mémoire en quantité raisonnablement faible (une centaines par rapport à des dixaines de milliers), c'est déjà largemnt optimisé pour le GC, puisque celui-ci a beaucoup moins de références à gérer.

Quelle taille mémoire occupe l'application? Le truc qui tue le GC, en général, c'est la mémoire. La difficulté de son travaill est proportionnel à la taille de la HEAP. Le GC aura beaucoup moins de boulot avec une application occupant 200M de ram qu'avec une application occupant 32G.
La swap est aussi un problème. Comme le ramasse miette circule un peu dans toutes la mémoire java, un segment swappé sur disque ne le reste pas longtemps. donc bien s'assurer que physiquement, la machine où tourne ton application assez de mémoire que pour ne pas swapper

Le coup de mettre les références à null ne sert qu'à éviter les fuite de mémoire. Exemple:

X référence Y qui référence Z. On garde la référence vers X (on en a encore besoin dans l'application) elle n'est pas collectable. Mais on aura plus besoin de Y. Alors on met X.y à null pour que Y soit collectable. Mais il n'y a aucune raison de mettre Y.z à null.

Par contre, ca a été beaucoup recommandé à certains moment pour les JVM embarquée, où le ramasse miette était beaucoup plus limité et donc pouvait avoir des problèmes avec le nettoyage des références circulaires.

Un dernier truc qui tue aussi le ramasse miette: être aux limites de la mémoire disponible en java. Genre avoir 200M et tourner constament à 199M occupés, avec juste 1M de marge pour les nouveaux objets. Dans ce cas là, le GC va faire des full GC (qui sont couteux) à tour de bras pour récupérer un maigre 50k de mémoire, que vous allez immédiatement reconsommer.
Il vaut bien mieux avoir un application qui remplis progressivement un tampon libre de la heap de 50M avec de temsp en temps le GC qui passe et purge 40M


Pour optimiser votre applicaiton, il n'y a pas 36.000 stratégies: vous faites tourner dans un profiler et vous analysez le rapport pour savoir où optimiser.

[Elendhil]

Sinon depuis l'update 14 de la jvm de Sun , tu as le nouveau ramasse miette :
"The Garbage First Collector".

Je ne sais pas si il est utilisé par défaut , donc tu si c'est pas le cas tu peux essayer de l'activer . Il est censé améliorer significativement les performances surtout sur des machines multi-coeurs.

Sinon tu peux essayer d'utiliser le GPU , je pense que cela doit être l'idéal si ton application fait principalement du traitement d'image. Enfin tout dépend de la carte graph ^^

Tu peux essayer de voir du côté d'openGL avec JOGL ou alors cuda avec le biding jacuzzi.

[ToTo13]

Sinon tu peux essayer d'utiliser le GPU , je pense que cela doit être l'idéal si ton application fait principalement du traitement d'image. Enfin tout dépend de la carte graph ^^

Tu peux essayer de voir du côté d'openGL avec JOGL ou alors cuda avec le biding jacuzzi.

Non pour OpenGL/JOGL, oui pour Cuda mais c'est galère en Java :@