Discussion :

[Ange_blond]

Bonjour,

Je me heurte à un probleme de gestion mémoire.
Rien de nouveau en C++ me direz vous, mais néanmoins...

Contexte :
Sur le projet que je developpe, on utilise des modeles objets plutot lourds, des libraires externes, etc... du bon gros projet de 120k lignes en somme.

Le soucis c'est qu'a présent, les données utilisées/generées (ex: graphe de scene) sont tellement devenues imposantes que la mémoire sature rapidement, déclenchant des magnifiques crash.
Je cherche donc un moyen de gerer les allocations mémoire pour éviter ou tout du moins limiter la portée des crash.
De ce que j'ai vu/lu les operateurs new levent des exception std::bad_alloc si necessaire, sans pour autant retourner NULL.

Ce que je voudrais éviter c'est de devoir encadrer chaque new par un manager d'exception (bloc try...catch).
Un seul bloc pourrait faire l'affaire s'il est placé à haut niveau, en tout cas je pense, mais la complexité est telle qu'il n'est pas évident de localiser le bon endroit pour le placer.

Ma question est donc de savoir si le fait de placer un seul bloc (ou une poigné) à haut niveau dans le code (par haut niveau j'entend le main() ou les méthodes principales) pourrait suffire à gerer les crash.
D'autre part, le catch permettra de ne pas crasher l'application, mais l'état des elements alloués en mémoire à ce moment ne sera selon moi pas connu, et donc il sera difficile de continuer l'execution du programme.

Il y a aussi la possibilité de surcharger/redéfinir l'operateur new, mais je doute que celà aide...

Voilà j'espere etre resté compréhensible, si ce n'est pas le cas n'hesitez pas à demander des clarifications.

Merci de votre aide.

[poukill]

Bonjour,
Ce que je voudrais éviter c'est de devoir encadrer chaque new par un manager d'exception (bloc try...catch).

Je te conseille en effet d'éviter ça !

Ma question est donc de savoir si le fait de placer un seul bloc (ou une poigné) à haut niveau dans le code (par haut niveau j'entend le main() ou les méthodes principales) pourrait suffire à gerer les crash.

Tu réponds tout seul à ta question : attraper une exception, c'est bien. La traiter c'est super. Mais continuer ton programme c'est une autre paire de manche. Surtout que recevoir une std::bad_alloc, ça ferme un peu le bal, car si l'utilisateur voulait vraiment faire ça, bah que peut il faire d'autre ?

Il y a aussi la possibilité de surcharger/redéfinir l'operateur new, mais je doute que celà aide...

Pour trouver qui a lancé et où si, mais à part ça...
http://loulou.developpez.com/tutorie.../partie1/#L2.2

Au final, tu devrais peut-être prendre un profiler et déterminer comment réduire ton empreinte mémoire, si besoin en diminuant l'optimisation. Réécrire les parties concernées ensuite ?
Ou alors prendre un PC plus musclé !

[Emmanuel Deloget]

Tu peux aussi jeter un coup d'oeil à set_new_handler().

Il y a des merveilles qu'on ne devrait pas cacher...

En gros, un handler est appelé chaque fois qu'une allocation échoue. Il peut ainsi libérer de la mémoire, et redonne le contrôle a new qui recommence, etc.

Bien évidemment, il y a un mécanisme d'arrêt parce que sinon, tu aurais bien des difficultés à sortir d'une telle boucle

[LittleWhite]

Bonjour,

Et si la surcharge de l'opérateur new vous permettez de renvoyer NULL lors d'un échec, est ce que cela peut convenir ?

[jblecanard]

Salut

As tu passé un coup de Valgrind sur ton projet, pour vérifier si ça ne fuit pas un peu partout ? Dans un projet comme ça, de petites fuites locales avoir un effet désastreux si elles se retrouvent dans des boucles.

[JolyLoic]

Pour trouver qui a lancé et où si, mais à part ça...
http://loulou.developpez.com/tutorie.../partie1/#L2.2

Attention : J'ai déjà signalé que ce code était non conforme, puisqu'il fait un #define sur un mot clef, mais ce problème n'est plus depuis peu un problème purement théorique. En C++0x (et contre mon vote), il est actuellement prévu que le mot clef new soit réutilisé dans un autre contexte où ce #define ne passera pas. Donc ce code ne pourra pas compiler de code C++0x.

[Ange_blond]

Salut

As tu passé un coup de Valgrind sur ton projet, pour vérifier si ça ne fuit pas un peu partout ? Dans un projet comme ça, de petites fuites locales avoir un effet désastreux si elles se retrouvent dans des boucles.

Oui ça a été fait.
Mais le programme n'a pas(peu) de fuites. Il s'agit réellement d'un consommation énorme parce qu'il doit gerer des masses de données, et sans cesse allouer/désalouer de la mémoire pour les afficher...

Bonjour,

Et si la surcharge de l'opérateur new vous permettez de renvoyer NULL lors d'un échec, est ce que cela peut convenir ?

J'y avais pensé oui, mais il faudrait tout de meme tester tous les new pour savoir si ça a échoué ou non, ce qui revient à coller des try catch partout au final.

Tu peux aussi jeter un coup d'oeil à set_new_handler().

Il y a des merveilles qu'on ne devrait pas cacher...

Je jette un oeil de ce pas merci. je ne connaissais pas mais ça pourrait s'avérer utile

Tu réponds tout seul à ta question : attraper une exception, c'est bien. La traiter c'est super. Mais continuer ton programme c'est une autre paire de manche. Surtout que recevoir une std::bad_alloc, ça ferme un peu le bal, car si l'utilisateur voulait vraiment faire ça, bah que peut il faire d'autre ?

Je vais tester une gestion qui va fermer le programme dans les regles, ou tout du moins éviter le crash à venir apres un bad_alloc.
Ce que je recherche c'est avant tout de la stabilité.

Au final, tu devrais peut-être prendre un profiler et déterminer comment réduire ton empreinte mémoire, si besoin en diminuant l'optimisation. Réécrire les parties concernées ensuite ?
Ou alors prendre un PC plus musclé !

Alors réécrire le code en quelques jours ça risque d'etre chaud
Et changer de PC... ben faut le dire au client mais j'arrete pas de le rabacher depuis 2 ans

Merci pour vos conseils, je vais continuer à creuser la question.
N'hesitez pas si vous avez encore des idées

[Emmanuel Deloget]

Si tu as beaucoup de données, peut-être peut tu tout simplement écrire un adapteur qui va en garder une grosse partie sur disque en attendant de t'en servir pour de vrai. Si c'est possible, il serait sage de combiner cette approche avec une notion de niveau de détails (premier niveau : pas beaucoup de données, mais une approximation de la totalité des données ; les niveaux en dessous sont de plus en plus détaillés ; voir ce qui se fait en mip mapping pour les jeux vidéo).

[Ange_blond]

Si tu as beaucoup de données, peut-être peut tu tout simplement écrire un adapteur qui va en garder une grosse partie sur disque en attendant de t'en servir pour de vrai. Si c'est possible, il serait sage de combiner cette approche avec une notion de niveau de détails (premier niveau : pas beaucoup de données, mais une approximation de la totalité des données ; les niveaux en dessous sont de plus en plus détaillés ; voir ce qui se fait en mip mapping pour les jeux vidéo).

C'est à dire que... c'est dejà le cas !
J'utilise des LOD qui sont paginé sur le disque et qui sont chargé depuis le disque à la runtime, et sont déchargé aussi à la runtime. (en fonction de la camera)
C'est ceci qui implique des mouvements massifs d'allocation/désallocation à la runtime et qu'il faut gerer car n'importe quand un gros paquet de données peut etre alloué ou désaloué.

Sans ce systeme de LOD, ça ferait longtemps qu'on aurait cessé d'essayé de charger autant de données

[screetch]

le problème peut être que tes objets ont tous des tailles différentes, et que tu peux en mettre n'importe ou. C'est pour un jeu vidéo donc?

il existe d'autres possibilités de stockage qui permettent de charger et decharger plus "amicalement":

mettons que tu reserves de base un enaaaaurme bout de mémoire (pas trop hein )
ton "monde" (la liste des objets) est divisé ensuite en couches:
la couche 0 est ce qui est visible en permanence
la couche 1 est divisée en case; elle n'est chargée que si on est proche de cette case
la couche 2 itou, cases plus petites.
Les lods les plus precis sont donc dans la couche 2, la couche 0 contient les objets les plus imprécis

lorsque la caméra est en un point x, y: tu charges (de base) la couche 0, et tu la mets tout au debut de ta memoire
tu determines ensuite sur quelle "case" tu es, tu risques d'avoir besoin des cases alentours évidemment (donc mettons 9 cases de couche 1: la case sur laquelle tu es et les 8 cases autour). Tu les charges. Puis de même avec les 9 cases de couche 2.
Lorsque tu te deplaces, tu devras donc decharger certaines cases de couche 1 et 2 pour les remplacer par d'autres. L'astuce est alors souvent de faire des cases qui ont pratiquement le même cout; alors on vide une case dont on a pas besoin et on la remplace par une case dont on va avoir besoin.

Ca peut etre lourd si tu changes en permanence de case genre tu te promènes juste sur la frontière. Dans ce cas, il se peut que tu doives decharger les cases dont tu n'as plus besoin mais... que tu ne charge pas toujours les cases dont tu vas avoir besoin, tant que tu n'es pas sur que tu vas vraiment t'en servir.

Il faut donc gérer tes données par batch, pas individuellement, et tu charges tout d'un coup, pas un par un. Et pour ce faire tu peux utiliser les mêmes blocs de mémoire.
Si une case ne tient pas en mémoire c'est que la case est trop gourmande, il faut la retravailler (je part du principe d'un jeu vidéo ou on a le choix, hein, donc si tu n'as pas le choix pour une raison x ou y ca va être cotton).