Discussion :

[kaiser92]

Bonsoir a tous,

donc voila, j'ai une application que j'ai porte de java en c++ qui marche plutot bien. Elle utilise des compteurs de reference un peu partout.
Malheuresement elle contient des fuites memoires a cause de references cycliques. Mon object graph est tres complexe, m empechant d utliser des weak references
Apparement il faut utiliser un garbage collector mark&sweep pour regler ce probleme mais je n'y comprend pas grand chose, entre autre a cause de ces roots, ... Cela demande des connaissances sur la memoire virtuelle, les registres, les segments, ...
C'est un peu violent pour moi.
J'ai trouvé un code c, un conservative gc, il creer une root a partir de la stack, puis scanne la stack et recherche des pointeurs.
Comment cela peut-il marcher puisque la stack peut etre corrompue a tout moment.
Je cherche un truc simple remplacant le refcounting.
Merci de votre aide

[Lavock]

Je connais pas trop le sujet, mais je dirai que tu as 2 solutions : Repenser le design ou te tourner vers boost ou TR1 smart pointer...

PS : a moins d'y être vraiment obligé, le "Garbage Collector" en c++ c'est... assez moyen je trouve.

[white_tentacle]

Mon object graph est tres complexe, m empechant d utliser des weak references

Ton problème, ce n'est pas la complexité de l'objet graph, mais l'absence de responsabilité. Tu ne sais pas qui est responsable de la durée de vie de tes objets (classique dans un programme java, en C++ ça ne pardonne pas).

Commence par définir qui est responsable de tes objets, après, tu sauras où utiliser des weak_ptr. Eventuellement, si tu peux nous en dire un peu plus sur la structure de ton graphe (j'imagine qu'il est cyclique et orienté, au vu de tes problèmes).

PS : a moins d'y être vraiment obligé, le "Garbage Collector" en c++ c'est... assez moyen je trouve.

"C++ is the best garbage collected language, because it produces very little garbage" (Stroustrup, de mémoire). Bon, c'est un peu de la provoc cela dit, parce que destructeurs et garbage collectors ne font pas très bon ménage. Il y a du boulot à faire de ce côté.

[r0d]

Une autre possibilité: boost::graph
Tu auras une classe graphe toute prête, bien pensée et optimisée, ainsi que les principaux algorithmes (A*, etc.).

[loufoque]

parce que destructeurs et garbage collectors ne font pas très bon ménage. Il y a du boulot à faire de ce côté.

Il n'y a pas vraiment de boulot à faire, les cycles et les destructeurs sont des choses incompatibles car dans le cas d'un cycle il n'est pas possible d'appeler les destructeurs dans un ordre qui satisfasse que les membres de chaque classe ne soient pas détruits quand on en appelle son destructeur.
C'est pour moi une preuve supplémentaire que les cycles c'est plus un problème lié à une mauvaise conception qu'autre chose...

[kaiser92]

En fait, j'ai porté un code existant en java, bien sur le codeur ne se soucie guere du design, car java est bien plus simple, il suffit de se fier a la JVM qui est un peu plus intelligente que moi et arrive a gerer ces references cycliques.
Il m'a dit que(il bosse avec moi) que c'est impossible d'enlever ces references cycliques et auto-references.
Il s'agit d'une JavaScript compilé machine virtuelle. Grosso modo tu compiles un .js en un .cjs puis tu execute ce cjs avec mon code.
Un peu comme le projet SpiderMonkey qui lui utilise un GC.
En fait une fonction contient un prototype, qui lui contient la fonction, ....
Pour des raisons internes on veut pas utiliser spidermonkey, et on peux pas redisigner l'application, je doit faire avec.
L'objet graph est tellement complexe que casser manuellement les references cycliques est trop compliqué.
C'est certainement la meme raison qui fait que spidermonkey n'utilise pas le refcounting.
Je m'oriente donc vers un GC, et aurait aimé savoir si ca va pas me flinguer les performances.
Aussi j'ai trouvé un GC mark&sweep en c++, mais cela depend trop de la plateforme, localisation des objets en memoire, registres, stack, memoire virtuelle, ...
Je doit faire tourner mon programme sur Win32,WinMobile, Symbian, Mac et iPhone.
Des conseils seraient les bienvenus
Merci d'avance

[loufoque]

Je m'oriente donc vers un GC, et aurait aimé savoir si ca va pas me flinguer les performances.
Aussi j'ai trouvé un GC mark&sweep en c++, mais cela depend trop de la plateforme, localisation des objets en memoire, registres, stack, memoire virtuelle, ...

Tu peux faire du GC sans passer par une analyse de la pile et des registres, mais ça ne va pas être très efficace.
Sinon le GC c'est globalement efficace, enfin c'est un algorithme tout simple : de temps ou temps, en particulier quand tu n'as pas assez de mémoire libre, tu parcoures le graphe de tous tes objets et tu marques ceux que tu visites. Tu libères ensuite tous ceux qui n'ont pas été marqués.

[kaiser92]

Oui merci, et comment tu parcours ce graphe sans passer par la pile et le registres, tout la est la question.
Tous les Gc en c/c++ que j ai trouver parcours ce graphe via la pile, les registres et le data segment.
Tu pourrais eclaircir ce point stp.
Merci

[kaiser92]

Svp, pourriez-vous m'aider sur ce GC.
c'est sympa, je suis vraiement bloqué.

[bacelar]

.NET dispose de manière native d'un garbage collector "mark&sweep" (entre autre).
Le C++/CLI est l'extension .NET du C++.
Vous n'auriez qu'a faire de vos classes des classes managées (mot clé ref devant class et gcnew à la place de new) pour que leur instances soient gérer dans le garbage collector .NET.

[Médinoc]

Svp, pourriez-vous m'aider sur ce GC.
c'est sympa, je suis vraiement bloqué.

Eh bien pour ça, je pense qu'il faut garder une trace des références.
S'il n'y en avait que sur la pile, une liste simplement chaînée aurait pu suffire, avec une variable globale.

Mais vu que les références peuvent se faire et défaire dans un ordre autre que LIFO, j'imagine bien une liste doublement chaînée:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
class reference_base
{
private:
	reference_base *pPrevious;
	reference_base *pNext;
	static reference_base *pLast = 0;
protected:
	void *pGarbageCollectedObject;
public:
	reference_base()
	{
		/*Ajoute à la fin de la liste*/
		pNext = 0;
		pPrevious = pLast;
		pLast = this;
		if(pPrevious != 0)
			pPrevious->pNext = this;
	}
	~reference_base()
	{
		/*Supprime de la liste, où qu'on soit*/
		if(pPrevious != 0)
			pPrevious->pNext = pNext;
		if(pNext != 0)
			pNext->pPrevious = pPrevious;
		if(pLast == this)
			pLast = pPrevious;
	}
private:
	reference_base(reference_base const &);
	reference_base& operator=(reference_base const &);
 
};
template< class T >
class reference : private reference_base
{
public:
	reference(T* pObj) { Set(pObj); }
	reference(reference const &src) { Set(src.Get()); }
	reference& operator=(reference const &src) { Set(src.Get()); }
 
	T * Get() const { return static_cast< T* >(pGarbageCollectedObject); }
	void Set(T* pObj) {  pGarbageCollectedObject = pObj; }
};

L'inconvénient, c'est que ça augmente la taille d'une référence. Mais je pense que c'est inévitable, que leur liste soit centralisée ou distribuée.
De plus, il faudra peut-être y ajouter d'autres infos, comme l'adresse de l'objet qui les contient, etc.

[Médinoc]

Ou à la réflexion, il doit être possible de s'en sortir avec un équivalent de la réflexion, qui nécessiterait une liste chaînée simple dans la pile (plus un mécanisme spécial pour autoriser qu'une référence se trouve hors d'un objet managé). J'ai bien mon idée en tête, mais c'est compliqué à expliquer et à mettre en oeuvre...

[kaiser92]

.NET dispose de manière native d'un garbage collector "mark&sweep" (entre autre).
Le C++/CLI est l'extension .NET du C++.
Vous n'auriez qu'a faire de vos classes des classes managées (mot clé ref devant class et gcnew à la place de new) pour que leur instances soient gérer dans le garbage collector .NET.

impossible de faire ca, car je doit le faire en natif et le porter sur 4 OSes...

[Médinoc]

J'ai trouvé un code c, un conservative gc, il crée une root a partir de la stack, puis scanne la stack et recherche des pointeurs.
Comment cela peut-il marcher puisque la stack peut être corrompue a tout moment.

Généralement, on compte sur le fait qu'elle ne soit PAS corrompue...

[epsilon68]

je dirais que dans un graphe,
le responsable de la destruction des noeuds ne sont pas les noeuds,
sinon effectivement ca delete dans tous les sens :-)

je verrais bien un seul objet responsable de la creation et de la destruction des noeuds.

cet objet parcourirait ton graph pour passer a travers tous les noeuds (faisant attention aux cycles avec une pile) pour identifier ceux qui ne sont plus utilisés et les liberer (delete)...

mais effectivement il y aurait un cout memoire en plus puisqu'il faudra stoker
les noeuds une deuxieme fois.... inevitable.

<EDIT>
ou alors le delete d'un noeud le stokerait dans une liste
et le parcours de l'arbre verifie que ces noeuds dans cette liste sont bien liberer de toute reference

si on peut mettre cette liste en global alors on evite cet "inevitable" cout memoire en plus.
</EDIT>

a+

[epsilon68]

mais le probleme est de resoudre ce probleme de delete dans un seul objet graph ou dans tout le programme?

parce que si c'est dans tout le programme alors il faut manipuler des "references" comme Medinoc décrivait, avec ce cout memoire en plus, pas le choix.

[screetch]

tu as jeté un coup d'oeil a boehm GC ?

[kaiser92]

Oui je connais le Boehm GC, mais j'ai pas trouvé de projet visual c++ pour le compiler sur Win32. Et puis il me faut un truc portable, qui marche sur plusieurs OS, Win32/WinCE, Symbian et iPhone.
Tu saurais ou je pourrais trouver ce Boehm GC a compiler directement sur Visual studio.
J'ai pas trop envie de perdre du temps a galerer pour creer un vcproj avec toutes les options, ... et m'apercevoir que c'est pas portable du tout...
J'espere que tu me comprend.
Par ailleurs tous les gc en c++ que j'ai trouvé, sont
1. utilise VirualAlloc, ...
2. utilise la std library
Mes managers ne veulent pas en entendre parler.
Donc si le Boehm est portable c'est super, quelqu'un l'a déja utilisé?
Merci

[Goten]

Tes managers ne veulent pas entendre parler de la SL? Nerf ça va être dur.

[screetch]

ici on fait quand meme pas dans la magie
un GC est techniquement importable, il dépend totalement de l'OS. Boehm a été compilé pour Iphone ca c'est sur, linux et windows, mais sinon je ne sais pas

il y a un Makefile pour NMAKE de Visual C++ pour compiler avec Visual Studio, et il y a un configure/make pour les autres plate-formes.

et tu comprendras que moi je ne souhaite pas trop perdre du temps a te fournir des solutions clé en mains qui couteraient de mon temps (non rémunéré) avec les contraintes de TES boss (et pas des miens) pour que ca aille plus vite pour toi...