Je suis en train de développer un petit programme de dessin et j'ai besoin de retenir la liste des points dessinés par l'utilisateur avec la souris.

J'ai pensé aux Arraylists mais vu que je ne les ai pas vraiment encore abordées, je me suis dit que je devrais arriver à retenir mes points avec une liste chainée. La référence sur le premier point est un attribut de la classe qui s'occuppe du dessin et ensuite chaque point possède la référence sur le suivant.

Mon problème -> Je bloque au niveau de la méthode effacer de ma classe de dessin: est-ce que si je mets simplement la référence du premier point sur null, les autres seront-ils automatiquement candidats au ramasse-miettes ou est-ce qu'ils vont rester en mémoire ?
Car s'ils restent en mémoire je dois trouver un moyen de mettre toutes les références aux points suivants à null et pour l'instant je n'y arrive pas sans faire planter l'application.

d'avance

Je pense que tu n'as pas de soucis à te faire au niveau du ramasse miettes.

En effet, de proche en proche, toutes tes cellules vont devenir candidates au ramasses miettes si tu met le premier "pointeur" sur NULL.

Celle qui était pointée (ou référencée, comme tu prèferes) [La deuxieme cellule] va devenir candidate, car la seule référence sur cette cellule a disparu.
Mais si celle-ci est détruite, la suivante devient candidate au ramasse miette aussi, car la seule réference dessus était dans une cellule qui a disparue.
Et ainsi de suite de proche en proche.

Je demande quand même confirmation à un expert de Java (que je suis loin d'être), mais je pense que les choses devraient se passer ainsi.

Attention, les choses seront différentes si tu t'amuses à garder en mémoire (ailleurs) des références supplémentaires sur les dites cellules.

Bref, à mon avis, pas de soucis à te faire.
Quand tu détruira ta première cellule (ou quand tu mettra à NULL le pointeur sur la cellule suivante) tout le reste suivra, mais éventuellement longtemps après (je ne sais pas tous les combien de temps le ramasse miettes se déclenche-t'il; peut-être même uniquement quand la mémoire commence à sa faire rare).
Mais je pense que ceci n'est pas ton soucis, le principal est d'être sur que à terme, tout ce barda est candidat à la disparition.

merci pour ta réponse rapide !

Je pensais justement à ce cas de figure, où tous les points deviendraient candidats à la chaine rien qu'en supprimant le premier point. Même si cela n'aurait sûrement pas eu d'incidences sur mon programme, autant coder de façon propre

oui la machine virtuelle java devrait faire le menage comme il faut.
Il y a plein de facon de faire du garbage collecting, mais de meoire en java cela se fait par une analyse de composante connexe. Donc si plus aucun objet deriver de la focntion Main ou de la fonction de depart d'un thread n'a access au premier maillon de ta liste, alors celui ci sera retire. Et si aucun des maillons de ta liste n'est accessible par autre chose que le premier maillon de la liste, ils seront retirs egalement.

On peut cependant se demander en combien de temps ils vont etre retirer de la memoire. Ce n'est pas bien clair en java. On peut demander de faire passer un tour de garbage collector (Runtime.gc()). Mais je ne sais pas si on peut en obtenir un controle fin.

Logiquement, je dirais qu'ils ne seront pas collectés en même temps, mais un par un un à chaque activation du gc.

Je ne pense pas que le gc de Java explore récursivement les composants "references" d'un objet lorsqu'il libère le dit objet.

Par contre, à chaque fois qu'une cellule est détruite, le nombre de référence sur la cellule suivante vaut zéro (dans l'hypothèse mentionnée où tu n'a pas d'autres références), et cette cellule suivante devient à son tour candidate pour le prochain reveil du gc.

Enfin, logiquement, cela devrait se passer ainsi si je m'en tiens à ce qu'on m'a raconté sur le gc Java.

Par contre, y'a-t'il quelqu'un pour confirmer ou infirmer ce que j'ai dis au sujet de l'activation du gc uniquement lorsque la mémoire se fait rare ?

godrik merci!

saleGauss Mon livre sur Java (Programmer en Java de Delannoy) confirme presque ce que tu dis: "dans la plupart des cas, le ramasse-miettes ne se déclenche que lorsque la mémoire commence à se faire rare". Ce qui est certain, c'est qu'on ne maîtrise pas le moment de l'appel au gc...

salegauss, tu ne peux pas faire un garbage collector comme cela.
Quand tu fais un garbage collector, tu es oblige de faire une recherche de composante connexe, un ref counting ne suffit pas. Considere une liste doublement chaine. Chaque maillon de la liste a deux references entrantes et les extermite ont une reference entrante. Si tu te contente de ref counting, tu ne liberera JAMAIS cette liste doublement chaine. tu es donc oblige de faire une recherche des elements qui sont sont pas connexe avec main ou un thread ou un objet global...

Cela etant dit, il y a probablement egalement des heuristiques dans la machine virtuelle qui fonctionne a base de ref counting. Pour se passer d'une recherche potentiellement couteuse alors qu'il y a des objets que l'on peut supprimer a faible cout.

Oui effectivement, je n'avais pas fais attention à ce genre de choses là.

Ca tombe bien, je n'ai pas encore implémenté de gc, et je vais pas tarder à devoir me poser la question du comment le faire.
Merci pour l'explication très clair en tout cas.

Et effectivement, j'espere qu'il y a quand même une heuristique qui aiguille un peu cette recherche.
Il serait dommage d'aller chercher à supprimer des choses bien planquées alors que des elements auraient leur compteur à zéro.
Mais effectivement, cela ne suffit pas.

Merki !

"Cela etant dit, il y a probablement egalement des heuristiques dans la machine virtuelle qui fonctionne a base de ref counting. Pour se passer d'une recherche potentiellement couteuse alors qu'il y a des objets que l'on peut supprimer a faible cout. "

C'est pas sur du tout. À part dans quelques GC assez simples (ceux qui sont écrit pour le C++ par exemple) qui fonctionnent entièrement à base de ref counting, j'aurais tendence à dire que ça n'est pas utilisé. Car mettre à jour des compteurs de références est très couteux par rapport au gain que ça apporte comme "indice" au GC. En tout cas je sais que les GC de Caml et de .NET (qui sont deux des GC les plus performants) n'utilise pas de ref counting mais uniquement des analyses de vivacité pour déterminer quels sont les objets vivants (i.e. on parcours tout les objets de pointeurs en pointeurs et on regarde ceux que l'on n'atteint jamais, mais c'est très bien pensé avec des objets que l'on regarde plus ou moins souvent).

deux liens sur le sujet qui peuvent être intéressant :
http://msdn.microsoft.comom/en-us/library/ee787088.aspx
http://www.ocaml-tutorial.org/garbage_collection

"Il serait dommage d'aller chercher à supprimer des choses bien planquées alors que des elements auraient leur compteur à zéro.
Mais effectivement, cela ne suffit pas. "

Usuellement un GC ne fonctionne pas comme ça non plus. Il va s'activer rarement, mais lorqu'il le fait (typiquement parce qu'une certaine quantité de mémoire est atteinte ou que le tas est rempli) alors il vas supprimer tout les objets qui peuvent l'être (au moins au sein d'une génération donnée (Cf les liens de mon post précédent)) qu'ils soient facilement détectable ou "bien caché". Un système temps réel est une exception à tout ça, mais c'est assez spécifique.

Merci pour ces precisions dnob,
C'est vrai que j'ai entendu que le GC de caml etait tres performants.
Ce que je me rappelle de son fonctionnement (ou peut etre un de ses fonctionnement) est qu'il fait du copy and sweep. C'est a dire qu'il copy recursivement tous les objets a partir de main dnas une memoire secondaire et qu'en suite, il degage la memoire primaire et swap les deux memoires.

J'avais trouve ca rigolo, c'est un peu du double buffering de memoire.