Un GC en natif dans le langage, comme en Java, j'arrive à
imaginer comment il peut fonctionner. Mais un GC extérieur
au langage, comme en C++, comment fait-il pour savoir qu'un
objet n'est plus référencé ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Loïc Joly
Bonjour,
Un GC en natif dans le langage, comme en Java, j'arrive à imaginer comment il peut fonctionner. Mais un GC extérieur au langage, comme en C++, comment fait-il pour savoir qu'un objet n'est plus référencé ?
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
-- Loïc
Bonjour,
Un GC en natif dans le langage, comme en Java, j'arrive à
imaginer comment il peut fonctionner. Mais un GC extérieur
au langage, comme en C++, comment fait-il pour savoir qu'un
objet n'est plus référencé ?
Peut-être trouveras tu ton bonheur ici :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
Un GC en natif dans le langage, comme en Java, j'arrive à imaginer comment il peut fonctionner. Mais un GC extérieur au langage, comme en C++, comment fait-il pour savoir qu'un objet n'est plus référencé ?
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
-- Loïc
Sylvain Togni
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
-- Sylvain
Peut-être trouveras tu ton bonheur ici :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels
sont les pointeurs encore utilisés, commence par scanner les 3
emplacements suivants :
- les registres
- la pile
- les données statiques
Mais comment peut-il savoir si la valeur contenue dans un registre
ou dans une adresse mémoire correspond à un pointeur, et pas à un
entier ou à quelque chose d'autre ?
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
-- Sylvain
Loïc Joly
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
J'ai pas lu les détails, juste survolé, donc je peux me planter, mais si j'ai bien compris, il ne sait pas. Mais dans le pire des cas, ça lui fait garder vivant quelques pointeurs sans raison d'être, mais ce n'est pas forcément très grave.
C'est en tout cas ce que j'ai déduit de sa FAQ : http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html
-- Loïc
Peut-être trouveras tu ton bonheur ici :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels
sont les pointeurs encore utilisés, commence par scanner les 3
emplacements suivants :
- les registres
- la pile
- les données statiques
Mais comment peut-il savoir si la valeur contenue dans un registre
ou dans une adresse mémoire correspond à un pointeur, et pas à un
entier ou à quelque chose d'autre ?
J'ai pas lu les détails, juste survolé, donc je peux me planter, mais si
j'ai bien compris, il ne sait pas. Mais dans le pire des cas, ça lui
fait garder vivant quelques pointeurs sans raison d'être, mais ce n'est
pas forcément très grave.
C'est en tout cas ce que j'ai déduit de sa FAQ :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
J'ai pas lu les détails, juste survolé, donc je peux me planter, mais si j'ai bien compris, il ne sait pas. Mais dans le pire des cas, ça lui fait garder vivant quelques pointeurs sans raison d'être, mais ce n'est pas forcément très grave.
C'est en tout cas ce que j'ai déduit de sa FAQ : http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html
-- Loïc
kanze
Sylvain Togni wrote:
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
Il ne sait pas. Si la valeur peut être un pointeur, il suppose que c'est un pointeur.
Ça donne des faux positifs, et il lui arrive de garder de la mémoire qu'il aurait pû libérer. Mais pas autant que ça : pour qu'il le considère comme un pointeur intéressant, il faut que la valeur correspond à une adresse dans un bloc alloué. Dans une application typique, ça ne correspond qu'à un faible pourcent des valeurs, et ne comprend jamais des valeurs « fréquentes » (du genre 0, 1, -1...).
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain Togni wrote:
Peut-être trouveras tu ton bonheur ici :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver
quels sont les pointeurs encore utilisés, commence par scanner
les 3 emplacements suivants :
- les registres
- la pile
- les données statiques
Mais comment peut-il savoir si la valeur contenue dans un
registre ou dans une adresse mémoire correspond à un pointeur,
et pas à un entier ou à quelque chose d'autre ?
Il ne sait pas. Si la valeur peut être un pointeur, il suppose
que c'est un pointeur.
Ça donne des faux positifs, et il lui arrive de garder de la
mémoire qu'il aurait pû libérer. Mais pas autant que ça : pour
qu'il le considère comme un pointeur intéressant, il faut que la
valeur correspond à une adresse dans un bloc alloué. Dans une
application typique, ça ne correspond qu'à un faible pourcent
des valeurs, et ne comprend jamais des valeurs « fréquentes »
(du genre 0, 1, -1...).
Je peux dire que j'utilise le collecteur de Boehm
systèmatiquement sur toute nouvelle application, et que je n'ai
jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai
adopté cette pratique il y a peu, et je n'ai pas commencé tant
d'applications nouvelles depuis:-). N'empêche que j'ai quand
même fait pas mal d'essais, et qu'il m'a toujours donné
entièrement satisfaction.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Peut-être trouveras tu ton bonheur ici : http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
En partie. Si j'ai bien compris, le GC de Boehm, pour trouver quels sont les pointeurs encore utilisés, commence par scanner les 3 emplacements suivants : - les registres - la pile - les données statiques Mais comment peut-il savoir si la valeur contenue dans un registre ou dans une adresse mémoire correspond à un pointeur, et pas à un entier ou à quelque chose d'autre ?
Il ne sait pas. Si la valeur peut être un pointeur, il suppose que c'est un pointeur.
Ça donne des faux positifs, et il lui arrive de garder de la mémoire qu'il aurait pû libérer. Mais pas autant que ça : pour qu'il le considère comme un pointeur intéressant, il faut que la valeur correspond à une adresse dans un bloc alloué. Dans une application typique, ça ne correspond qu'à un faible pourcent des valeurs, et ne comprend jamais des valeurs « fréquentes » (du genre 0, 1, -1...).
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain Togni
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté « aléatoire » du fonctionnement ne m'inspire pas trop confiance ;-).
Sinon, au vu de tes premières experiences avec, quel est ton sentiment quant au service rendu par un GC en c++ ? Est-ce que ça facilite vraiement la vie ? Est-ce que ça n'introduit pas d'autres problèmes ?
-- Sylvain
Je peux dire que j'utilise le collecteur de Boehm
systèmatiquement sur toute nouvelle application, et que je n'ai
jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai
adopté cette pratique il y a peu, et je n'ai pas commencé tant
d'applications nouvelles depuis:-). N'empêche que j'ai quand
même fait pas mal d'essais, et qu'il m'a toujours donné
entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté « aléatoire »
du fonctionnement ne m'inspire pas trop confiance ;-).
Sinon, au vu de tes premières experiences avec, quel est ton
sentiment quant au service rendu par un GC en c++ ? Est-ce que ça
facilite vraiement la vie ? Est-ce que ça n'introduit pas d'autres
problèmes ?
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté « aléatoire » du fonctionnement ne m'inspire pas trop confiance ;-).
Sinon, au vu de tes premières experiences avec, quel est ton sentiment quant au service rendu par un GC en c++ ? Est-ce que ça facilite vraiement la vie ? Est-ce que ça n'introduit pas d'autres problèmes ?
-- Sylvain
kanze
Sylvain Togni wrote:
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté « aléatoire » du fonctionnement ne m'inspire pas trop confiance ;-).
Bof. Il faut dire que je travaille surtout sur des systèmes Unix. Où il y a déjà pas mal d'autres aléas aussi : quel pourcentage du temps CPU tu vas recevoir, combien de temps il faut pour lire des données en provenance d'un fichier sur un système de fichiers monté NFS, etc. Dans la pratique, pour beaucoup d'applications, le GC ne va pas en ajouter des aléas mesurables.
Sinon, au vu de tes premières experiences avec, quel est ton sentiment quant au service rendu par un GC en c++ ? Est-ce que ça facilite vraiement la vie ? Est-ce que ça n'introduit pas d'autres problèmes ?
Il faut dire que ma démarche a été déclenchée par un problème qui aurait justement exigé du code supplémentaire sans un GC -- une classe qui contenait des pointeurs à des structures que parfois elle allouait elle-même, mais qui parfois étaient des objets statiques. En jouant sur de différents constructeurs, et en ajoutant des flags, je m'en serais tiré, mais c'est bien plus simple à laisser au GC le problème.
Le resultat, aussi, c'est que j'ai plus supprimé énormement de pointeurs intelligents, ce qui rendait le code plus simple, et en cas de threads, beaucoup plus performant.
Pour la reste, je suis encore au stade des essais, mais jusqu'ici, le seul « problème » que je constate, c'est qu'il fallait remplacer mes remplacements de l'operator new/operator delete, qui servaient au debuggage. Et que je n'ai pas encore trouvé le temps d'en implémenter des versions orientées GC. Étant donné que une des motivations principales de ces opérateurs étaient de detecter des fuites de mémoire, je dirais que ce n'est pas la fin du monde.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain Togni wrote:
Je peux dire que j'utilise le collecteur de Boehm
systèmatiquement sur toute nouvelle application, et que je
n'ai jamais eu de problème. (Mais ce n'est pas trop
concluant -- j'ai adopté cette pratique il y a peu, et je
n'ai pas commencé tant d'applications nouvelles depuis:-).
N'empêche que j'ai quand même fait pas mal d'essais, et
qu'il m'a toujours donné entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté «
aléatoire » du fonctionnement ne m'inspire pas trop confiance
;-).
Bof. Il faut dire que je travaille surtout sur des systèmes
Unix. Où il y a déjà pas mal d'autres aléas aussi : quel
pourcentage du temps CPU tu vas recevoir, combien de temps il
faut pour lire des données en provenance d'un fichier sur un
système de fichiers monté NFS, etc. Dans la pratique, pour
beaucoup d'applications, le GC ne va pas en ajouter des aléas
mesurables.
Sinon, au vu de tes premières experiences avec, quel est ton
sentiment quant au service rendu par un GC en c++ ? Est-ce que
ça facilite vraiement la vie ? Est-ce que ça n'introduit pas
d'autres problèmes ?
Il faut dire que ma démarche a été déclenchée par un problème
qui aurait justement exigé du code supplémentaire sans un GC --
une classe qui contenait des pointeurs à des structures que
parfois elle allouait elle-même, mais qui parfois étaient des
objets statiques. En jouant sur de différents constructeurs, et
en ajoutant des flags, je m'en serais tiré, mais c'est bien plus
simple à laisser au GC le problème.
Le resultat, aussi, c'est que j'ai plus supprimé énormement de
pointeurs intelligents, ce qui rendait le code plus simple,
et en cas de threads, beaucoup plus performant.
Pour la reste, je suis encore au stade des essais, mais
jusqu'ici, le seul « problème » que je constate, c'est qu'il
fallait remplacer mes remplacements de l'operator new/operator
delete, qui servaient au debuggage. Et que je n'ai pas encore
trouvé le temps d'en implémenter des versions orientées GC.
Étant donné que une des motivations principales de ces
opérateurs étaient de detecter des fuites de mémoire, je dirais
que ce n'est pas la fin du monde.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je peux dire que j'utilise le collecteur de Boehm systèmatiquement sur toute nouvelle application, et que je n'ai jamais eu de problème. (Mais ce n'est pas trop concluant -- j'ai adopté cette pratique il y a peu, et je n'ai pas commencé tant d'applications nouvelles depuis:-). N'empêche que j'ai quand même fait pas mal d'essais, et qu'il m'a toujours donné entièrement satisfaction.)
Moi j'hésite à faire le pas. Il faut dire que le côté « aléatoire » du fonctionnement ne m'inspire pas trop confiance ;-).
Bof. Il faut dire que je travaille surtout sur des systèmes Unix. Où il y a déjà pas mal d'autres aléas aussi : quel pourcentage du temps CPU tu vas recevoir, combien de temps il faut pour lire des données en provenance d'un fichier sur un système de fichiers monté NFS, etc. Dans la pratique, pour beaucoup d'applications, le GC ne va pas en ajouter des aléas mesurables.
Sinon, au vu de tes premières experiences avec, quel est ton sentiment quant au service rendu par un GC en c++ ? Est-ce que ça facilite vraiement la vie ? Est-ce que ça n'introduit pas d'autres problèmes ?
Il faut dire que ma démarche a été déclenchée par un problème qui aurait justement exigé du code supplémentaire sans un GC -- une classe qui contenait des pointeurs à des structures que parfois elle allouait elle-même, mais qui parfois étaient des objets statiques. En jouant sur de différents constructeurs, et en ajoutant des flags, je m'en serais tiré, mais c'est bien plus simple à laisser au GC le problème.
Le resultat, aussi, c'est que j'ai plus supprimé énormement de pointeurs intelligents, ce qui rendait le code plus simple, et en cas de threads, beaucoup plus performant.
Pour la reste, je suis encore au stade des essais, mais jusqu'ici, le seul « problème » que je constate, c'est qu'il fallait remplacer mes remplacements de l'operator new/operator delete, qui servaient au debuggage. Et que je n'ai pas encore trouvé le temps d'en implémenter des versions orientées GC. Étant donné que une des motivations principales de ces opérateurs étaient de detecter des fuites de mémoire, je dirais que ce n'est pas la fin du monde.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
