voici les courbes de mémoire d'une application java. dites-moi tous ce que vous y voyez.
 
à gauche c'est le lancement de l'application.
 
pour ceux qui ne dinstingueraient pas les couleurs, celle du haut c'est la mémoire alloué par la JVM, celle du milieu, la mémoire allouée par l'application dans la JVM, celle d'en bas, la mémoire libre dans la JVM.
 
la courbe du bas déconne un peu (y'a des doigts qui vont sauter chez les devs du plugin).

Je suis pas un spécialiste Java, mais voilà ce que j'observe :
 

• Que de la mémoire est rapidement allouée au début, par blocs, mais plafonnée par la suite.
• Que le GC ne cherche pas à libérer plus de 50 % de la mémoire disponible.
• Que la mémoire libérée par le GC n'est pas rendue immédiatement disponible.
• Que le GC libère de la mémoire avant une demande de ressources (queue).
• Que le GC semble attendre un seuil avec de collecter.
• Qu'il fait parfaitement son affaire dans l'espace mémoire disponible.

Alors ?

moi j'y vois que ça libère tout d'un coup quand ça arrive à la limite maximale, et que ça doit sacrément se ressentir ... d'ailleurs sur le deuxième décrochage, c'est directement suivi qu'une grosse allocation, elle a pas du être effectuée aussi vite que souhaitable celle là.
 
après au niveau de la mémoire totale, et bien l'occupation se fait de manière assez chaotique, bref ça fait encore du yoyo, ça doit encore une fois ce sentir : au démarrage l'application bouffe la moitié de la mémoire dont elle aurra besoin (~8000), et bien ça se fait dans la douleur (y a bien une dizaine de bonds ...)

1) oui et non, on voit que la JVM passe sont temps à faire des récupérations (descentes de la ligne du milieux) et à demander du rab de mémoire au système (montée sur la ligne du haut) ce qui veut dire qu'il aurait fallu en donner plus au démarrage, pour diminuer le temps de démarrage (faire un full GC et demander de la mémoire au système, c'est assez long).
2) j'aurais dû activer la trace pour le vérifier, c'est probablement qu'il a déjà éliminé *tout* ce qui était éliminable (full GC), mais le doute subsiste.
3) si, la trace du bas est décallée à cause d'un bug, si tu la lis bien, la mémoire est rendue avant d'avoir été récupérée, ce qui est impossible.
4) oui, on voit ça sur les pics du démarrage, lors d'une demande d'allocation trop importante on commence par récupérer de la mémoire avant de re-tenter l'allocation, puis, si c'est insuffisant, la JVM re-demande de la mémoire au système.
5) effectivement, et on voit que ce seuil et lié à la mémoire effectivement disponible pour la JVM
6) si on est sûr que les grosses dents de scie sont bien des full GC, alors oui, 50% d'occupation est un chiffre pas mal en général. Dans le cas précis de mon application je serais plutôt partisant d'un fort taux d'occupation (au prix d'une application très lente), car c'est une application secondaire (un truc type chat).
 
 
Taz > je réponds même pas.
 
Par contre, on voit d'autre choses, par exemple, dans les montées c'est pas lisse alors que la consomation semble globalement linéaire, c'est dû à l'éboueur de la première génération. si on regarde bien, les grandes montées sont faites de segments plus petits : c'est les GCs de la deuxième génération.
 
Les grosses descentes sont dûes à un gros coup de GC, probablement un full (j'ai pas activé les traces du gc pour le vérifier)

pourquoi tu me réponds même pas ? j'ai dit la même chose : démarrage poussif et grande dents de scie pas très efficaces

on est certain de la fiabilité des courbes ? vu que le refresh est périodique, ca a peut etre des effets sur l'allure des courbes

Parce que tu commences tes conneries avec du "pas très efficaces". C'est fini, je t'invite à virer ton drapeau.

non, on est jamais sûr de rien. Surtout vu la gueule du plugin.

LOOL...c surtout le décallage entre la mémoire libre et la mémoire occupée...
 
si on considère que  
Memoire totale VM = Mémoire libre VM + mémoire occupée programme, il est impossible qu'on est plus de mémoire libre que memoire totale VM - mémoire occupée programme...ce qui est le cas sur le graphe...
 
tu pourrais essayer le même graph en forçant un taux de refresh plus important, genre 1 au lieu de 5 ?

je t'ai dit que la courbe jaune est foireuse, y'a des points qui sont passés à la trappe sur X.
 
Je peux la refaire avec un meilleur taux de raffraichissement, mais ça va être encore plus foireux.

enfin c toujours ça, ca donne une bonne idée de ce que ton appli a dans le ventre...
 
ca m'a permis de découvrir que l'instanciation d'une classe ca coute une fortune en temps proco...et que donc dans la mesure du possible je pense qu'il vaut mieux réutiliser des objets existants...même si ma dernière tentative en swing s'est soldée par un échec foireux...mais je pense que c parce que j'avais du static dans le bouzin...

ben tu as dû rater un truc alors.

ah bon, je savais pas que j'étais venu troller ... que ça soit java ou pas, je m'en bats bien. Et ce genre de problème de grande dents de scie, je l'ai déjà rencontré et j'avais affiné les seuils entre les génération de mon gc pour éviter les gros accoups comme ça.
quand au problème de 36 rellocations au démarrage, ce problème il est partout GC ou pas.

pkoi ?
 

 
Y'a 2 trucs :  
- l'init est le truc qui bouffe le plus de temps proco
- pour une raison que j'ignore, si je trouche pas à l'appli (qui doit normalement etre dans un état d'attente), ma conso de ram augmente...alors que l'appli ne fait rien...g donc un peu le même schéma que toi, et je comprends pas pkoi

je peux voir la courbe sur plus longtemps ?
 
je peux voir le code de la classe en question ?

je te fais ça...
 
euh le code de la classe tu veux quoi exactement ??? parce que là c tt l'appli, et y'a plein de classes...tu veux la classe qui gère le GUI ?

graph mis à jour...en gros ca fait le pattern en boucle...mà ou ca a l'air bizarre, c que je me suis amuser à affoller l'appli en cliquant partout...après c revenu au même pattern...
pour le code tu veux l'appli ???

pourquoi tu dis pattern ?

aux temps pour moi : motif...motif dans le graph....ca monte, un coup de GC, ca redescent, puis ca remonte, etc....ca fait ca en boucle...

PlateformBuilder.

c là :  
 
http://jubijub.free.fr/images/
 
Je t'ai mis le platformBuilder, et Visualisation, qui gère les panneaux de visu...
 
le code est sale, mal commenté, et je débute un peu en java...mais c ma première utilisation potable de gridBagLayout, et j'en suis pas peu fier
 
c encore en plein debug, d'où la méthode init qui contruit des objets à la con pour tester...
 
si tu veux je te rar le truc et je le met à dispo, si tu veux lancer l'appli pour tester...

Bon, ok, j'avais pas vu : c'est du swing, c'est normal que la création soit super-lente. Surtout que la création du premier truc swing initialise tout le système swing à lui tout seul (ce qui est tellement gros qu'on désactive le JIT pour pas fausser ses stats).

et pour l'histoire de la ram qui joue au yoyo ?

c'est normal, ça me parrait pas alarmant. tu sens le ralentissement à l'utilisation ?

non, aucun...faut dire que ca fait pas bézef de trucs à la fois non plus :  
 
g un arbre qui contient un type d'objet sur les feuilles, et chaque branche représente un autre type d'objet.
 
Un clic sur l'extremité de la branche juste avant la feuille reconstruit le nom de l'objet, et va le chercher dans un treeset
Un clic sur la feuille récupére le UserObject, l'objet dont g besoin....
 
ensuite, je fais un tas de get pour chopper des string ou des booleans, et je construis un panneau de visualisation qui affiche ca joliement...
 
ca va pas chier loin...

Bon, j'ai pas lu tous vos posts mais comme j'ai déjà vu ce genre de graphe, vala :
- les grosses descentes sont évidemment liées au GC
- ces descentes ne correspondent pas à une libération mémoire effective car la JVM, une fois qu'elle a bouffé de la mémoire, elle la rend pas dispo aux autres applis avant qu'elle se termine.
- donc le GC ne fait que libérer de la mémoire pour permettre à d'autres objets d'en prendre sans bouffer au final une OurOfMemoryError.
 
Voilou. Mais p'têt que ça a déjà été dit