Discussion :

[deneb]

Note : ce débat a commencé sur le débat C# Versus Java


J'ai vu pas mal de monde dans ce thread citer le garbage collector de Java comme un avantage...
N'y a t-il personne d'autre que moi pour penser que cette gestion auto est la pire connerie que Sun ait commise sur ce language (qui par ailleurs est plutôt réussi) ?
Le concept même de GC est pour moi un non sens... Quel que soit le language.

J'ai aussi utilisé un GC en C++ dans mon jeune temps et la conclusion fut la même : merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!

[adiGuba]

Le concept même de GC est pour moi un non sens...quelque soit le language.

Je ne suis pas d'accord, le GC est un gros avantage. D'ailleurs, si je ne me trompe pas, .NET utilise également un GC...

merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!

Le GC de Java ne m'a jamais posé de tel problème...
Maintenant il est facile de faire exploser le GC en lui faisant créer un grand nombre d'objet temporaire... mais c'est plus une faute de programmation qu'un problème de GC à mon avis...

Maintenant, c'est sûr que selon la cible de l'application, ce n'est pas forcément la meilleure solution et que la gestion manuelle de la mémoire peut être plus performante...

a++

[deneb]

En fait je ne vois pas en quoi le GC apporte un plus...
Dans le pire des cas, sachant que le GC est là, le développeur ne se soucie pas le moins du monde de sa mémoire...et ça monte, ça monte.

Donc vous me direz que la présence d'un GC ne dispense pas d'une gestion stricte de sa mémoire...(j'en sais qq chose).
Mais dans ce cas si je dois continuer à gérer ça moi même, autant le faire jusqu'au bout car je sais le faire bien mieux que le GC...et surtout au bon moment !

Je n'ai jamais eu de pb de fuite de mémoire en C++ alors qu'en Java c'est assez fréquent et en plus elles sont beaucoup plus difficiles à repérer.

Bref, le GC c'est sympa pour les débutants on pour faire des petits progs, mais pour écrire un serveur d'appli ...

[adiGuba]

En fait je ne vois pas en quoi le GC apporte un plus...
Dans le pire des cas, sachant que le GC est là, le développeur ne se soucie pas le moins du monde de sa mémoire...et ça monte, ça monte.

Non cela ne monte pas puisque le GC libèrera la mémoire inutilisé !!!

Le GC apporte plusieurs avantages :

• On n'a pas à se soucier de la durée de vie d'un objet. Il sera quand même désalloué proprement lorsqu'il ne sera plus utilisé.
• On peut facilement partager un objet entre plusieurs autres objets, sans se soucier de devoir le désallouer (le GC s'en chargera lorsque l'objet n'est plus référencé). Cela permet d'utiliser le pattern des classes immuables et ainsi d'économiser de nombreuses créations d'objet (pas de copie d'objet à tout bout de champs !).
• Le GC optimise les allocations/désallocations, en effectuant des traitements par bloc. Si tu crées/détruits 1000 objets, le GC ne fera que quelques allocations/désallocations de mémoire (voir aucune). Dans bien des cas cela peut être plus performant qu'une gestion manuelle...
• La gestion des objets alloué par le GC est très rapide, car il alloue des blocs de mémoire entiers.

Bien sûr cela a des désavantages :

• A un instant précis, il consomme plus de mémoire qu'il n'en a besoin, afin de prévenir les futures allocations. Par exemple au démarrage de l'application il alloue par défaut 2 Mo de mémoire (si je ne me trompe pas).
• Il peut être nécessaire de le configurer selon les besoins de l'application (Pour plus de détail, lire : La gestion de la mémoire par le Garbage Collector par Romain Guy)
• On ne connait pas le moment exact de la libération des objets (même si on peut le savoir en utilisant les PhantomReference : Comprendre les Références en Java)

Donc vous me direz que la présence d'un GC ne dispense pas d'une gestion stricte de sa mémoire...(j'en sais quelque chose).

Disons que la gestion de la mémoire est différente. En Java il est nécessaire de "perdre" les référence des objets inutilisés afin d'autoriser le GC à les libérer. La plupart des "memory leak" en Java viennent du fait que l'on conserve des références inutilement...

Mais dans ce cas si je dois continuer à gérer ça moi même, autant le faire jusqu'au bout car je sais le faire bien mieux que le GC...et surtout au bon moment !

Si tu le dis...
Personnellement je préfère me concentrer sur le code métier de mon application...

Je n'ai jamais eu de pb de fuite de mémoire en C++ alors qu'en Java c'est assez fréquent et en plus elles sont beaucoup plus difficiles à repérer.

J'ai eu des problèmes de mémoire avec pas mal de langage, mais je ne vois pas en quoi elles sont plus fréquentes et plus difficile à repérer avec Java ???

Bref, le GC c'est sympa pour les débutants on pour faire des petits progs, mais pour écrire un serveur d'appli ...

Au contraire, le GC n'est pas très utile aux débutants ! D'ailleurs dans des langages comme le C/C++, ils utilisent généralement pas l'allocation dynamique...

C'est dans le cadre de grosses applications que le GC devient très utile, puisqu'on a généralement de gros besoins d'allocation dynamique...


a++

[deneb]

Débat intéressant isn't it ?
En fait on fait plus de leak avec Java qu'en C++ car justement Java facilite (encourage ?) la gestion à la méthode porcus.
Alors qu'en C++ j'utilisais une stragégie d'allocation désallocation très stricte...j'ai perdu cette bonne habitude du fait du GC. (ainsi que la quasi totalité de développeurs java avec qui j'ai pu bosser, et il y en a un paquet).
Le partage d'objets n'est pas du tout un pb sans GC...ou ça met en évidence un mauvais design.

D'une manière générale, je trouve que le fait de déresponsabiliser le developpeur sur la gestion de la mémoire tend à faire des programmes qui consomment le triple de mémoire que nécessaire.

[adiGuba]

En fait on fait plus de leak avec Java qu'en C++ car justement Java facilite (encourage ?) la gestion à la méthode porcus.

Non. Je pense juste que la "méthode porcus" est juste plus vite sanctionné pour une application C++ que Java à cause (ou grâce) au GC qui "corrigera" un certain nombre de ces problèmes...

Mais quel que soit le langage la "méthode porcus" entrainera des problèmes

Le partage d'objets n'est pas du tout un pb sans GC...ou ça met en évidence un mauvais design.

Mais il faut avouer que c'est bien plus complexe à mettre en oeuvre sans GC...

D'une manière générale, je trouve que le fait de déresponsabiliser le developpeur sur la gestion de la mémoire tend à faire des programmes qui consomment le triple de mémoire que nécessaire.

Il faut surtout savoir travailler avec les outils qu'on a : si on utilise un GC cela ne vaut pas dire que l'on doit complètement ignoré la gestion de la mémoire.

Au contraire il faut prendre en compte le GC, et limiter au minimum le scope des différents objets temporaires...

Pour moi il s'agit plus d'erreur de programmation (ou de fainéantise)...



Enfin concernant les "memory leak" : avec un GC on ne peut pas vraiment parler de "memory leak" puisque cela signifie que l'on conserve toujours une référence vers l'objet...

a++

[deneb]

Non. Je pense juste que la "méthode porcus" est juste plus vite sanctionné pour une application C++ que Java à cause (ou grâce) au GC qui "corrigera" un certain nombre de ces problèmes...
Mais quel que soit le langage la "méthode porcus" entrainera des problèmes

Tout à fait exact.
Le problème avec Java c'est qu'en laissant croire qu'il gère la mémoire, il encourage les développeurs à ne pas se soucier du tout de cette question. Tu n'a qu'à voir le nombre de questions de développeurs relatifs à ce sujet ici et ailleurs "au secours j'ai plus de mémoire"...

Mais il faut avouer que c'est bien plus complexe à mettre en oeuvre sans GC...

T'exagères
Un service global qui alloue les objets que les sous services doivent se partager...c'est pas super compliqué.

Il faut surtout savoir travailler avec les outils qu'on a : si on utilise un GC cela ne vaut pas dire que l'on doit complètement ignoré la gestion de la mémoire.
Au contraire il faut prendre en compte le GC, et limiter au minimum le scope des différents objets temporaires...

C'est ça que je conteste...
Si le machin n'est pas capable de gérer parfaitement le pb de bout en bout (et ça n'est évidemment pas possible), je préfère le faire moi même.
Sinon on reste le cul entre deux chaise et...le boulot n'est jamais bien fait.
Ce que je veux dire c'est qui si je dois faire un effort pour gérer ma mémoire, alors ça ne me coute pas plus cher, ni en temps ni en fatigue cérébrale de gérer moi même les désallocations. Et dans ce cas, je n'aurais plus à subir le GC.

Pour moi il s'agit plus d'erreur de programmation (ou de fainéantise)...

Un programmeur est naturellement fainéant.
Il faut en tenir compte dans les choix d'architecture qu'on fait

Enfin concernant les "memory leak" : avec un GC on ne peut pas vraiment parler de "memory leak" puisque cela signifie que l'on conserve toujours une référence vers l'objet...

Ceci est parfaitement exact !
Leak est un abus de language de ma part. Il s'agit plus d'accumulation de références inutiles (fuite de mémoire).

[adiGuba]

Tu n'a qu'à voir le nombre de questions de développeurs relatifs à ce sujet ici et ailleurs "au secours j'ai plus de mémoire"...

Le problème est un peu différent : Java et le GC utilise une zone mémoire nommée heap. Par défaut elle vaut 2 Mo et ne peut utiliser au maximum que 64 Mo. Si une application utilise plus de 64Mo on obtiendra une exception même si le système d'exploitation possède encore plein de mémoire libre (il faut spécifier une taille maximum plus grande au lancement de l'application pour résoudre cela) ! C'est une notion spécifique à Java et non pas au GC. Il y a d'ailleurs une RFE pour modifier cela...

Du coup si une application doit utiliser beaucoup de données (64 Mo ce n'est pas énorme de nos jours) elle se retrouve vite à l'étroit...

T'exagères
Un service global qui alloue les objets que les sous services doivent se partager...c'est pas super compliqué.

Non ce n'est pas compliqué à codé... mais ca l'est à mettre en place, car il faut adapter chacune des classes avec ce principe. Grosso-modo tu fais une partie du travail du GC...

En C (j'ai très peu fait de C++), à chaque fois que j'utilisais une fonction qui maniait des pointeurs, je devais regarder dans la doc pour savoir comment c'était alloué et comment je devais libérer proprement la mémoire...

Et j'ai également vu pas mal de programmes qui ne libéraient pas correctement la mémoire... mais comme il s'agissait de petit "batch" les effets n'étaient pas vraiment méchant...

Si le machin n'est pas capable de gérer parfaitement le pb de bout en bout (et ça n'est évidemment pas possible), je préfère le faire moi même.

Le GC fait bien son boulot... mais il ne peut pas libérer des objets dont tu conserves une référence. La principale contrainte est donc de ne pas laisser trainer les références des objets qui ne sont plus utilisés... Ce n'est pas vraiment la mort

Ce que je veux dire c'est qui si je dois faire un effort pour gérer ma mémoire, alors ça ne me coute pas plus cher, ni en temps ni en fatigue cérébrale de gérer moi même les désallocations.

Je pense au contraire que cela coute plus cher à la fois en temps et en fatigue... au début tout du moins...

Un programmeur est naturellement fainéant.

C'est pourquoi je préfère laisser le boulot au GC

a++

[deneb]

Le problème est un peu différent : Java et le GC utilise une zone mémoire nommé heap. Par défaut elle vaut 2 Mo et ne peut utiliser au maximum que 64 Mo.[...] Du coup si une application doit utiliser beaucoup de données (64 Mo ce n'est pas énorme de nos jours) elle se retrouve vite à l'étroit...

Beuh..tu me charie à m'expliquer ça
Ca fait 20 ans que je développe (enfin maintenant en hobiste parce que je suis passé du coté obscur) dont 6 ans en Java...

Non ce n'est pas compliqué à codé... mais ca l'est à mettre en place, car il faut adapté chaque des classes avec ce principe. Grosso-modo tu fais une partie du travail du GC...

Bof...c'est une question de design relative à la notion de "responsabilités".
C'est valable pour la gestion des allocations comme pour tout le reste.
Un objet qui alloue une ref et qui la largue dans la nature dans plus jamais la revoir et une erreur de design.

En C (j'ai très peu fait de C++), à chaque fois que j'utilisais une fonction qui maniait des pointeurs, je devais regarder dans la doc pour savoir comment c'était alloué et comment je devais libérer proprement la mémoire...

Voila...ça explique pourquoi tu aime le GC
Si tu avais codé suffisamment longtemps en C/C++ tu aurais vu qu'après avoir codé comme un cochon quelques temps, tu mets petit à petit en place des stratégies de gestion de la mémoire très efficaces et qui ne te demandent plus le moindre effort intellectuel.

Et j'ai également vu pas mal de programme qui ne libéraient pas correctement la mémoire... mais comme il s'agissait de petit "batch" les effets n'étaient pas vraiment méchant...

C'est effectivement fréquent.
Je ne dis d'ailleurs pas qu'en C++ on ne fait pas de leaks, on oublie toujours de libérer un objet !
Par contre un simple petit coup de Purify (à l'époque...il doit y avoir encore mieux maintenant)...et tout est parfaitement clean.

Le GC fait bien son boulot... mais il ne peut pas libérer des objets dont tu conserves une référence. La principale contrainte est donc de ne pas laisser trainé les références des objets qui ne sont plus utilisé... Ce n'est pas vraiment la mort

Il fait TRES bien son boulot, là n'est pas le pb.
Le pb c'est qu'il ne peut pas faire ce qui est impossible. Or, libérer la mémoire au bon moment...c'est pas possible, sauf pour le développeur.

Je pense au contraire que cela coute plus cher à la fois en temps et en fatigue... au début tout du moins...

Au début...

C'est pourquoi je préfère laisser le boulot au GC
a++

Bon je suis pas sûr de te convaincre là

[10_GOTO_10]

Le GC fait bien son boulot... mais il ne peut pas libérer des objets dont tu conserves une référence. La principale contrainte est donc de ne pas laisser trainé les références des objets qui ne sont plus utilisé... Ce n'est pas vraiment la mort

C'est là qu'est le problème: J'utilise un objet A qui utilise un objet B qui utilise aussi l'objet A (et dans un système complexe, les références circulaires sont loin d'être rares). Je n'ai plus besoin de l'objet A, donc je détruit sa référence. Mais l'objet A n'est pas détruit parce qu'il est encore utilisé par l'objet B. Et l'objet B n'est pas détruit parce qu'il est encore utilisé par l'objet A. Ces deux objets resteront donc jusqu'à la fin de l'application !

[deneb]

C'est là qu'est le problème: J'utilise un objet A qui utilise un objet B qui utilise aussi l'objet A (et dans un système complexe, les références circulaires sont loin d'être rares). Je n'ai plus besoin de l'objet A, donc je détruit sa référence. Mais l'objet A n'est pas détruit parce qu'il est encore utilisé par l'objet B. Et l'objet B n'est pas détruit parce qu'il est encore utilisé par l'objet A. Ces deux objets resteront donc jusqu'à la fin de l'application !

Si je ne m'abuse le GC est assez malin pour reperer ce type de cas...ce qui n'est d'ailleurs pas très compliqué, puisqu'il s'agit d'un sous graphe formant une composante connexe sans entrée...(j'me la pète là ! )

[10_GOTO_10]

Ce qui veut dire qu'il fait régulièrement un calcul (certainement récursif, en tous cas assez complexe) sur un graphe qui peut avoir des centaines ou des milliers de noeuds ? Est-ce qu'il reste encore un peu de temps processeur pour l'appli elle-même ?

[adiGuba]

Beuh..tu me charie à m'expliquer ça
Ca fait 20 ans que je développe (enfin maintenant en hobiste parce que je suis passé du coté obscur) dont 6 ans en Java...

Ben en même temps je ne connais pas ton parcours
De plus ce sujet est potentiellement lu par d'autres personnes qui ne le savent pas forcément...

Le pb c'est qu'il ne peut pas faire ce qui est impossible. Or, libérer la mémoire au bon moment...c'est pas possible, sauf pour le développeur.

Je suis tout à fait d'accord avec toi : avec un GC (celui de Java en tout cas) il n'est pas possible de choisir le moment où la mémoire sera libérer, et cela peut poser des problèmes avec certain type d'application.

Mais je n'ai pas dit que le GC était LA solution... Il y a des applications où l'utilisation d'un GC n'est pas souhaitable.
Par contre je trouve qu'il s'agit d'une solution plus que correcte dans bien des cas.

Bon je suis pas sûr de te convaincre là

Non je suis un fervent défenseur du GC

Sans rire : je connait les optimisation qu'il est possible de faire avec une gestion manuelle de la mémoire et des pointeurs... mais bien souvent l'utilisation d'un GC simplifie grandement le travail pour une différence finale minime...

(...) Ces deux objets resteront donc jusqu'à la fin de l'application !

Si je ne m'abuse le GC est assez malin pour reperer ce type de cas... (...)

En effet ce cas là est bien sûr géré (et heureusement d'ailleur... sinon le GC serait inutilisable !)

Le code source ci-joint le montre bien (en utilisant des PhantomReference pour déterminer le moment où les références seront désalloué).

Ce qui veut dire qu'il fait régulièrement un calcul (certainement récursif, en tous cas assez complexe) sur un graphe qui peut avoir des centaines ou des milliers de noeuds ?

Tu peux lire l'article de Romain cité plus haut pour plus de détail sur le GC de Java : La gestion de la mémoire par le Garbage Collector

Est-ce qu'il reste encore un peu de temps processeur pour l'appli elle-même ?

Bien souvent il en offre plus qu'une gestion manuelle !!!

Par exemple si tu prend le cas d'une boucle qui crée un nouvel objet temporaire à chaque itération, par exemple :

Code :

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

1
2
3
for (int i=0; i<1000; i++) {
            Object temp = new Object[1024];
        }

Avec une gestion manuelle, on aurait 1000 allocations mémoire, suivi de 1000 libérations...
Avec le GC, ces allocations/libérations seront regroupé, et donc moins fréquentes...
En exécutant ce code avec l'option -verbose:gc qui affiche les actions du GC, et j'obtiens 4 parcours :

Code :

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

1
2
3
4
[GC 892K->105K(5056K), 0.0016256 secs]
[GC 998K->105K(5056K), 0.0005996 secs]
[GC 999K->105K(5056K), 0.0002923 secs]
[GC 1001K->105K(5056K), 0.0001104 secs]

Et bien sûr dans d'autre cas il sera moins performant qu'une gestion manuelle... mais il reste "personnalisable" afin de l'adapter à ses besoins...



a++

[deneb]

C'est vrai que le GC de Java est bien écrit et je veux bien admettre que pour certains il facilite la tâche....pour créer d'autres problèmes

Pour ce qui est des perfs meilleurs par contre, c'est pas avec ton exemple que tu va me convaincre. Allouer un tableau à chaque tour d'une boucle c'est assez marrant...avec un new Object[1000][1024] ça marche plus.

Ce que je regrette c'est :
1 : qu'il déresponsabilise les développeurs qui ne gerent plus du tout leur mémoire...ce qui va même jusqu'à leur faire oublier qu'elle est limitée.
2 : dans certains types d'application (et pas de bol on est pile dedans puisqu'on développe un serveur d'appli) un GC qui bosse quand il veut et bouffe du CPU en même temps pendant que les requêtes clients...c'est pas acceptable.

Bref ce que je voudrais moi, c'est une option no-gc...histoire que ceux qui veulent se palucher la gestion à la main puissent le faire.

[adiGuba]

Pour ce qui est des perfs meilleurs par contre, c'est pas avec ton exemple que tu va me convaincre. Allouer un tableau à chaque tour d'une boucle c'est assez marrant...avec un new Object[1000][1024] ça marche plus.

En effet : parce que la taille du tableau est d'environ 4 Mo. Donc le GC est obligé d'allouer plus de mémoire que les 2Mo initiales. Et comme il s'agit d'objet temporaire il prefèrera libérer la mémoire plutôt que d'en allouer encore.

Donc il supprime réellement le tableau précédent à chaque itération : on se retrouve dans le même cas de figure qu'une gestion manuelle de la mémoire...

Il serait ici préférable d'augmenter le heap pour limiter le nombre de libération...

1 : qu'il déresponsabilise les développeurs qui ne gerent plus du tout leur mémoire...ce qui va même jusqu'à leur faire oublier qu'elle est limitée.

Cela déresponsabilise un peu les développeurs... peut-être...

Mais que ce soit avec un GC ou sans, dans une "grosse" application on est obligé de prendre en compte la mémoire...

2 : dans certains types d'application (et pas de bol on est pile dedans puisqu'on développe un serveur d'appli) un GC qui bosse quand il veut et bouffe du CPU en même temps pendant que les requêtes clients...c'est pas acceptable.

Les majors collections sont en effet coûteuse, mais on peut améliorer cela en modifiant les tailles min/max du heap, ou en utilisant un GC concurent...
Et si cela se produit trop souvent, c'est également que l'application consomme beaucoup de mémoire. Le fait qu'elle soit géré manuellement ne résoudra pas forcément le problème.

Bref ce que je voudrais moi, c'est une option no-gc...histoire que ceux qui veulent se palucher la gestion à la main puissent le faire.

Une option no-gc je ne pense pas que ce soit possible (en Java), étnt donné que le langage est basé sur l'utilisation du GC...

Mais un mot clef permettant de libérer manuellement un objet (s'il n'y a plus d'autres références vers celui-ci), c'est vrai que cela pourrait être utile, du style :

Code :

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

1
2
3
4
Object o = new Object();
...
o = null-gc;
// o vaut null et le GC tentera de le libérer

Mais bon c'est quand même assez limité je trouve...

a++

[deneb]

En effet : parce que la taille du tableau est d'environ 4 Mo. Donc le GC est obligé d'allouer plus de mémoire que les 2Mo initiales. Et comme il s'agit d'objet temporaire il prefèrera libérer la mémoire plutôt que d'en allouer encore.

Donc il supprime réellement le tableau précédent à chaque itération : on se retrouve dans le même cas de figure qu'une gestion manuelle de la mémoire...

Il serait ici préférable d'augmenter le heap pour limiter le nombre de libération...


Cela déresponsabilise un peu les développeurs... peut-être...

Mais que ce soit avec un GC ou sans, dans une "grosse" application on est obligé de prendre en compte la mémoire...



Les majors collections sont en effet coûteuse, mais on peut améliorer cela en modifiant les tailles min/max du heap, ou en utilisant un GC concurent...
Et si cela se produit trop souvent, c'est également que l'application consomme beaucoup de mémoire. Le fait qu'elle soit géré manuellement ne résoudra pas forcément le problème.



Une option no-gc je ne pense pas que ce soit possible (en Java), étnt donné que le langage est basé sur l'utilisation du GC...

Mais un mot clef permettant de libérer manuellement un objet (s'il n'y a plus d'autres références vers celui-ci), c'est vrai que cela pourrait être utile, du style :

Code :

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

1
2
3
4
Object o = new Object();
...
o = null-gc;
// o vaut null et le GC tentera de le libérer

Mais bon c'est quand même assez limité je trouve...

a++

Nop, moi ce que je veux c'est tout simplement:

Object ref = new Object();
// La JVM réserve la place pour mon instance dans le heap.
ref.dispose();
// LA JVM marque la zone free. Mon pointeur devient invalide...mais mon objet est libéré.

C'est ce pointeur vers une zone non controlée qui gène les architecte de Java.
A la limite, ça peut se résoudre en rajoutant un mot clé au language :
free ref;
///marque la zone free et met ref à null.

On va voir ce qu'ils en disent sur le forum Sun

[had35]

Une option no-gc je ne pense pas que ce soit possible (en Java), étnt donné que le langage est basé sur l'utilisation du GC...

Mais un mot clef permettant de libérer manuellement un objet (s'il n'y a plus d'autres références vers celui-ci), c'est vrai que cela pourrait être utile, du style :

Code :

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

1
2
3
4
Object o = new Object();
...
o = null-gc;
// o vaut null et le GC tentera de le libérer

Mais bon c'est quand même assez limité je trouve...

a++

Je trouve aussi que ça n'aurait pas vraiment d'intérêt. En revanche, une syntaxe qui permette de demander au gc de ne pas prendre de ressource pendant une certaine période de temps ou sur un bloc d'instruction (quitte à interdire la construction d'objet dans ce bloc) serait à mon avis bien plus profitable et permettrait de résoudre une des principale faiblesse du gc.
Ca pourrait ressembler à quelque chose comme ça :

Code :

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

1
2
3
4
no-gc {
    //bloc d'instruction
}

ou bien

Code :

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

1
2
System.no_gc(1000);

[gorgonite]

perso, je pense qu'il faudrait d'abord se demander quelle genre de gc serait vraiment utile ?

en effet si, comme moi, vous étudiez un peu les compilateurs, vous remarquerez que nombre de reproches faits au gc sont souvent dûs à l'implémentation fort naïve du gc de la jvm de sun pendant fort longtemps... au début un simple compteur de références si je ne m'abuse

par ailleurs, loin de moi l'envie de congratuler crimosoft (cf mon avatar), je pense que dans des applications où l'on souhaite pouvoir effectuer des optimisations, il est certes fort appréciable de disposer d'une gc, mais à l'unique condition qu'elle nous laisse parfois garder la main... comme celle de .net avec le langage c# par exemple.

après, pour avoir fait beaucoup de c et d'assembleur, il est vrai que la gestion de la mémoire (allocation et libération) peut parfois prendre une proportion non négligeable de projets qui aurait pu être faits plus simplement sans ce "détail", surtout quand le but n'est pas d'optimiser à mort...

[divxdede]

Alors je vais faire une peu de "dévanalyse" (joli le mot ^^)

Le Garbage Collector est un résultat de l'évolution du "développement".

Il y a 15 ans on devaient apprendre comment "swapper" le contenu de deux variables sans utiliser une troisième afin d'économiser au mieux l'utilisation de nos registres quand on développait en assembleur.

Nous avons eu droit ensuite à dés langages de plus haut niveau tel que le C. A cette époque les pro-assembleurs se targait de la mauvaise gestion mémoire / registres des programmes compilés en C

Quelques années plus tard, les languages POO sont apparus dont nottament Java. En plus des nouvelles méthodologies de conception, ces languages nous ont fait rentré dans une ère ou des APIs extremement riches ont elevés le niveau des développements.

Aujourd'ui on éleve encore un cranc ce niveau avec l'utilisation de ce qu'on appelle les "MiddleWare" (J2EE & Co).

L'ultime but de ces évolutions: Limiter la couverture de dévelopement aux parties métier uniquemement. Tout le reste doit être à la charge du language, outils, serveur et autres joyeuseries.

Le Garbage Collector se positionne trés bien dans cette optique et de ce fait il est trés bénefique. Oui les nostalgiques diront "Mais quand je manipule mes pointeurs, je sais quand je dois liberer mes allocations mémoire !! ".

Certe mais séparer le "system" du "metier" va dans le sens d'un code plus robuste et maintenable.

Alors un GRAND OUI au Garbage Collector.

PS: On pourrait par exemple faire la comparaison avec Hibernate qui gére la persistence à notre place. Ce qui en bon middleware nous permet de nous préoccuper des données avant tout (la persistence n'étant que de la technique). Certains diront toujours "oui mais en C je gére mes flushs au bon moment..." Ok, mais c'est le passé.......

[vosaray]

en effet si, comme moi, vous étudiez un peu les compilateurs, vous remarquerez que nombre de reproches faits au gc sont souvent dûs à l'implémentation fort naïve du gc de la jvm de sun pendant fort longtemps... au début un simple compteur de références si je ne m'abuse

LOL ! C'est vrai que le concept et l'implementation ne sont pas au meme niveau.

Mon avis perso et que le GC est une chose largement "utlisable" ( notez que je ne dis pas bonne ou mauvaise ).

Avec un peu de bouteille en Java (C# je ne connais pas) on fait vite gaffe aux references non utlisées et autres petites tracasseries liés au GC. Apres ca devient un refelxe.

Je ne trouve pas ca plus containgnant que de faire des free en C ou des destructeurs en C++ ...

Par contre mon principal reproche vise l'implementation du GC, qui sur versions differentes du runtime et en fonction des plateformes ne se comporte pas tout a fait de la meme maniere.

Par ailleurs il y a un manque cruel de doc "comprehensibles" pour optimser le GC. Avec le temps et l'experience on y arrive, mais je reconnais que c'est loin d'etre evident.

Apres pour ou contre, je reste neutre

J'aime programmer en Java, un language qui a d'excellentes qualités.

Pour cela il faut savoir utliser et bien parametrer le GC pour que les softs en tirent un avantage et pas des incovenients. C'est une contrainte de dev parmi d'autres sur un projet ....