S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
Wykaaa a écrit :S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
Tout ce que je sais sur le GC, c'est que dès qu'un objet n'est plus
accessible car il n'y a plus de référence pour l'atteindre, alors cet
objet est candidat au GC, mais on ne sait pas quand exactement l'objet
sera détruit.
Est-ce juste ?
PS : je ne suis pas développeur loin de là, je me contente d'apprendre
le langage Java.
Wykaaa a écrit :
S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
Tout ce que je sais sur le GC, c'est que dès qu'un objet n'est plus
accessible car il n'y a plus de référence pour l'atteindre, alors cet
objet est candidat au GC, mais on ne sait pas quand exactement l'objet
sera détruit.
Est-ce juste ?
PS : je ne suis pas développeur loin de là, je me contente d'apprendre
le langage Java.
Wykaaa a écrit :S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
Tout ce que je sais sur le GC, c'est que dès qu'un objet n'est plus
accessible car il n'y a plus de référence pour l'atteindre, alors cet
objet est candidat au GC, mais on ne sait pas quand exactement l'objet
sera détruit.
Est-ce juste ?
PS : je ne suis pas développeur loin de là, je me contente d'apprendre
le langage Java.
Bon courage. Est-ce ton premier langage ?
Bon courage. Est-ce ton premier langage ?
Bon courage. Est-ce ton premier langage ?
Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler, il
ne doit pas y avoir de problème sauf que plus de 80% des programmeurs
Java codent comme des pieds (ou avec leurs pieds, au choix). Hélas c'est
aussi vrai (encore plus probablement) pour les programmeurs C++.
Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler, il
ne doit pas y avoir de problème sauf que plus de 80% des programmeurs
Java codent comme des pieds (ou avec leurs pieds, au choix). Hélas c'est
aussi vrai (encore plus probablement) pour les programmeurs C++.
Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler, il
ne doit pas y avoir de problème sauf que plus de 80% des programmeurs
Java codent comme des pieds (ou avec leurs pieds, au choix). Hélas c'est
aussi vrai (encore plus probablement) pour les programmeurs C++.
Jean-Claude Arbaut a écrit :jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Jean-Claude Arbaut a écrit :
jlp wrote:
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Jean-Claude Arbaut a écrit :jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Wykaaa a écrit :Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler,
il ne doit pas y avoir de problème sauf que plus de 80% des
programmeurs Java codent comme des pieds (ou avec leurs pieds, au
choix). Hélas c'est aussi vrai (encore plus probablement) pour les
programmeurs C++.
Le soucis est que l'algorithmique est peu comprise de la plupart des
nouveaux programmeurs. Ainsi on voit fleurir ce genre de construction:
List<E> col = ....;
for(int i = 0; i<col.size(); i++) {
E element = col.get(i);
...
}
Or si la liste est une liste dont le size() est coûteux à calculer (par
exemple parce que c'est une liste chaînée écrite à la main), on se
retrouve à avoir du code en N^2 qui ne passe pas à l'échelle. Et même
dans l'absolu si le size() prend un temps constant à calculer, il faut
voir que l'appel d'une méthode est forcément plus coûteux que l'accès à
une variable locale. Aussi il vaudrait mieux écrire:
for(int i=0, max=col.size(); i<max; ++i) {
...
}
Ce qui donnera un code un peu plus performant (tout dépend du nombre
d'itérations et de ce que l'on calcule dans la boucle).
Ça n'est qu'un exemple.. mais on le trouve vraiment partout.
sam.
Wykaaa a écrit :
Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler,
il ne doit pas y avoir de problème sauf que plus de 80% des
programmeurs Java codent comme des pieds (ou avec leurs pieds, au
choix). Hélas c'est aussi vrai (encore plus probablement) pour les
programmeurs C++.
Le soucis est que l'algorithmique est peu comprise de la plupart des
nouveaux programmeurs. Ainsi on voit fleurir ce genre de construction:
List<E> col = ....;
for(int i = 0; i<col.size(); i++) {
E element = col.get(i);
...
}
Or si la liste est une liste dont le size() est coûteux à calculer (par
exemple parce que c'est une liste chaînée écrite à la main), on se
retrouve à avoir du code en N^2 qui ne passe pas à l'échelle. Et même
dans l'absolu si le size() prend un temps constant à calculer, il faut
voir que l'appel d'une méthode est forcément plus coûteux que l'accès à
une variable locale. Aussi il vaudrait mieux écrire:
for(int i=0, max=col.size(); i<max; ++i) {
...
}
Ce qui donnera un code un peu plus performant (tout dépend du nombre
d'itérations et de ce que l'on calcule dans la boucle).
Ça n'est qu'un exemple.. mais on le trouve vraiment partout.
sam.
Wykaaa a écrit :Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler,
il ne doit pas y avoir de problème sauf que plus de 80% des
programmeurs Java codent comme des pieds (ou avec leurs pieds, au
choix). Hélas c'est aussi vrai (encore plus probablement) pour les
programmeurs C++.
Le soucis est que l'algorithmique est peu comprise de la plupart des
nouveaux programmeurs. Ainsi on voit fleurir ce genre de construction:
List<E> col = ....;
for(int i = 0; i<col.size(); i++) {
E element = col.get(i);
...
}
Or si la liste est une liste dont le size() est coûteux à calculer (par
exemple parce que c'est une liste chaînée écrite à la main), on se
retrouve à avoir du code en N^2 qui ne passe pas à l'échelle. Et même
dans l'absolu si le size() prend un temps constant à calculer, il faut
voir que l'appel d'une méthode est forcément plus coûteux que l'accès à
une variable locale. Aussi il vaudrait mieux écrire:
for(int i=0, max=col.size(); i<max; ++i) {
...
}
Ce qui donnera un code un peu plus performant (tout dépend du nombre
d'itérations et de ce que l'on calcule dans la boucle).
Ça n'est qu'un exemple.. mais on le trouve vraiment partout.
sam.
Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Un programmeur qui écrit comme ça doit être envoyé en formation ou viré
sur le champ !
Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Un programmeur qui écrit comme ça doit être envoyé en formation ou viré
sur le champ !
Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Un programmeur qui écrit comme ça doit être envoyé en formation ou viré
sur le champ !
Wykaaa a écrit :Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Absolument.Un programmeur qui écrit comme ça doit être envoyé en formation ou
viré sur le champ !
Ca nécessiterait de reformer 99% des gens, y compris certains chez ibm :)
Sur le fond, ca dépend de la boucle et du temps qu'elle prend par
rapport au temps total. Si c'est une boucle occasionnelle, peu importe
de l'optimiser (je ne suis pas de ceux qui préconisent l'optim pour
l'optim).
Non, ce qu'il faut apprendre pour l'occasion c'est de savoir utiliser un
profiler pour trouver les goulets d'étranglement du programme plutôt que
de se trouver des excuses dans les lieux communs aujourd'hui largement
faux en disant "java ca rame" et en refusant de se remettre en cause en
examinant si on aurait par hasard pas codé de façon in-efficace ou
efficace sur des petites instances mais sans tenir compte du passage à
l'échelle.
Le jdk1.6.0_07 possède un outil sympa pour (entre autre) profiler:
jvisualvm. Savoir l'utiliser est un must à mon avis.
sam.
Wykaaa a écrit :
Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Absolument.
Un programmeur qui écrit comme ça doit être envoyé en formation ou
viré sur le champ !
Ca nécessiterait de reformer 99% des gens, y compris certains chez ibm :)
Sur le fond, ca dépend de la boucle et du temps qu'elle prend par
rapport au temps total. Si c'est une boucle occasionnelle, peu importe
de l'optimiser (je ne suis pas de ceux qui préconisent l'optim pour
l'optim).
Non, ce qu'il faut apprendre pour l'occasion c'est de savoir utiliser un
profiler pour trouver les goulets d'étranglement du programme plutôt que
de se trouver des excuses dans les lieux communs aujourd'hui largement
faux en disant "java ca rame" et en refusant de se remettre en cause en
examinant si on aurait par hasard pas codé de façon in-efficace ou
efficace sur des petites instances mais sans tenir compte du passage à
l'échelle.
Le jdk1.6.0_07 possède un outil sympa pour (entre autre) profiler:
jvisualvm. Savoir l'utiliser est un must à mon avis.
sam.
Wykaaa a écrit :Ton exemple n'est pas un problème spécifique à Java. Il est général,
même dans des langages non objets.
Absolument.Un programmeur qui écrit comme ça doit être envoyé en formation ou
viré sur le champ !
Ca nécessiterait de reformer 99% des gens, y compris certains chez ibm :)
Sur le fond, ca dépend de la boucle et du temps qu'elle prend par
rapport au temps total. Si c'est une boucle occasionnelle, peu importe
de l'optimiser (je ne suis pas de ceux qui préconisent l'optim pour
l'optim).
Non, ce qu'il faut apprendre pour l'occasion c'est de savoir utiliser un
profiler pour trouver les goulets d'étranglement du programme plutôt que
de se trouver des excuses dans les lieux communs aujourd'hui largement
faux en disant "java ca rame" et en refusant de se remettre en cause en
examinant si on aurait par hasard pas codé de façon in-efficace ou
efficace sur des petites instances mais sans tenir compte du passage à
l'échelle.
Le jdk1.6.0_07 possède un outil sympa pour (entre autre) profiler:
jvisualvm. Savoir l'utiliser est un must à mon avis.
sam.
Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== > Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$426a34cc@news.free.fr>)
Pour faire plus simple je la cite :
==== > Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== > Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Eric Razny a écrit :Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où
le développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== >> Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >>
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Je reconnais que ma réponse n'est pas tout à fait exacte. C'est une
simplification hative. En fait comme dit plus bas, chaque editeur à son
propre algorithme ( Il n'y a qu'à voir comme est géré le GC des Soft
References pour chaque editeur) . Mais quand la collection devient
complexe ( Collections de Collections de ...), voire partagée par des
threads concurrents, il vaut mieux forcer le dé-référencement dans le
code dans une clause finally d'un try/catch quand le besoin est.
Quant au lien sur la derniere strtégie de Garbage ( Garbage First) elle
est encore toute récente et prometeuse pour se rapprocher du "Temps
Reel" par rapport aux strategie GC Parallel / GC Concurrent plus
ancienne.
Eric Razny a écrit :
Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où
le développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$426a34cc@news.free.fr>)
Pour faire plus simple je la cite :
==== >> Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >>
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Je reconnais que ma réponse n'est pas tout à fait exacte. C'est une
simplification hative. En fait comme dit plus bas, chaque editeur à son
propre algorithme ( Il n'y a qu'à voir comme est géré le GC des Soft
References pour chaque editeur) . Mais quand la collection devient
complexe ( Collections de Collections de ...), voire partagée par des
threads concurrents, il vaut mieux forcer le dé-référencement dans le
code dans une clause finally d'un try/catch quand le besoin est.
Quant au lien sur la derniere strtégie de Garbage ( Garbage First) elle
est encore toute récente et prometeuse pour se rapprocher du "Temps
Reel" par rapport aux strategie GC Parallel / GC Concurrent plus
ancienne.
Eric Razny a écrit :Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où
le développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== >> Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...
Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
==== >>
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Je reconnais que ma réponse n'est pas tout à fait exacte. C'est une
simplification hative. En fait comme dit plus bas, chaque editeur à son
propre algorithme ( Il n'y a qu'à voir comme est géré le GC des Soft
References pour chaque editeur) . Mais quand la collection devient
complexe ( Collections de Collections de ...), voire partagée par des
threads concurrents, il vaut mieux forcer le dé-référencement dans le
code dans une clause finally d'un try/catch quand le besoin est.
Quant au lien sur la derniere strtégie de Garbage ( Garbage First) elle
est encore toute récente et prometeuse pour se rapprocher du "Temps
Reel" par rapport aux strategie GC Parallel / GC Concurrent plus
ancienne.
