Discussion :

[Luc Hermitte]

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

Le GC apporte plusieurs avantages :

a- On n'a pas a se soucier de la durée de vie d'un objet. Il sera quand même désallouer proprement lorsqu'il ne sera plus utilisé.

b- 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 nombreuse création d'objet (pas de copie d'objet à tout bout de champs !).

c- 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...

a- les GC ne concernent que la mémoire et ne touchent pas aux autres ressources. On se retrouve avec un code hétérogène : GC pour la mémoire, dispose-pattern ou autres approches pour les autres ressources

b- Le partage en lui même n'est pas ce qu'il y a de plus important, car c'est facile à réaliser, en C++ du moins.
En revanche les GC (hormis le premier de Java) savent gérer les cycles. Le plus gros avantage des GC, je trouve.

c- C'est un aspect assez connexe au principe des pools. Même en C et C++ on sait faire en détournant les opérations d'allocation. Et ce n'est pas forcément un avantage chez les GC (d'une VM à l'autre, il y a parfois des progres). On gagne certes un temps global d'exécution plus court, mais on peut avoir un effrondrement des perfs à tout moment car l'heure de la collecte est arrivée.

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

100% d'accord!


De mémoire, petit détail que je trouve assez intéressant la VM de .NET permet de distinguer la finalisation des objets, et en particulier de la rendre déterministe, de la collecte de la mémoire. Avec l'arrivée du C++/CLI, on a eu quelques papiers s'auto-congratulant sur un GC qui ne reniait pas le déterminisme et qui marchait main dans la main avec le RAII.

[deneb]

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é.......

La comparaison avec Hibernate n'est pas du tout un argument pour le GC, bien au contraire.

Hibernate rajoute certes une couche très abstraite entre les services métier et la JDBC, mais le travail qu'il réalise est énorme, tout autant que le temps de développement qu'il fait gagner. En contrepartie, il consomme un peu de ressources. Admettons qu'il bouffe 10%, je dois acheter une machine 10% plus puissante en contrepartie, je rajoute donc généreusement 300€ sur la facture. 300€ c'est le coût d'une journée de développement....Est-ce qu'Hibernate m'a fait gagner plus d'un jour de développement sur le projet ? Et oui, largement ! Donc Hibernate me fait économiser de l'argent !

Par contre pour le GC, je vois pas.

• Habitués à laisser le GC gérer la mémoire, les devs ne s'en occupent pas, il la gaspillent. Résultat, je dois acheter plus de RAM pour mes serveurs. Perte de fric.
• J'ai suffisament écrit de C et C++ pour savoir que la gestion de la mémoire ne prend pas de temps dev. Ou alors vous allez me dire que l'intialisation des variables aussi vous fait perdre du temps ?
• Ils passent plus de temps à chercher les fuites que je ne le faisait en C++, encore du fric perdu.
• Le GC bouffe des ressources pendant les requetes client, je dois donc encore ralonger pour la puissance de la machine. Ce qui n'impèche en rien les pauses pour collection et les questions des utilisateurs : "je comprend pas, ça marche bien votre truc, mais parfois il y a comme des arrets...on doit être trop nombreux sur le serveur non ?"...

[Médinoc]

Je l'ai déjà posté ailleurs, mais pour moi le GC devrait être un complément du comptage de références:

• Comptage de références : Un objet qui tombe à zéro références est détruit immédiatement (avant que le release() implicite ne retourne).
• GC : Repère et détruit les groupes isolés d'objets se référençant entre eux ("références cycliques") : Tourne en parallèle avec priorité basse, ou bien activé sur demande et quand l'application passe en idle, etc.

Note: Une gestion des "références faibles" peut également être utile pour éviter certaines "fuites" de mémoire.

[divxdede]

La comparaison avec Hibernate n'est pas du tout un argument pour le GC, bien au contraire.

Hibernate rajoute certes une couche très abstraite entre les services métier et la JDBC, mais le travail qu'il réalise est énorme, tout autant que le temps de développement qu'il fait gagner. En contrepartie, il consomme un peu de ressources. Admettons qu'il bouffe 10%, je dois acheter une machine 10% plus puissante en contrepartie, je rajoute donc généreusement 300€ sur la facture. 300€ c'est le coût d'une journée de développement....Est-ce qu'Hibernate m'a fait gagner plus d'un jour de développement sur le projet ? Et oui, largement ! Donc Hibernate me fait économiser de l'argent !

Par contre pour le GC, je vois pas.

• Habitués à laisser le GC gérer la mémoire, les devs ne s'en occupent pas, il la gaspillent. Résultat, je dois acheter plus de RAM pour mes serveurs. Perte de fric.
• J'ai suffisament écrit de C et C++ pour savoir que la gestion de la mémoire ne prend pas de temps dev. Ou alors vous allez me dire que l'intialisation des variables aussi vous fait perdre du temps ?
• Ils passent plus de temps à chercher les fuites que je ne le faisait en C++, encore du fric perdu.
• Le GC bouffe des ressources pendant les requetes client, je dois donc encore ralonger pour la puissance de la machine. Ce qui n'impèche en rien les pauses pour collection et les questions des utilisateurs : "je comprend pas, ça marche bien votre truc, mais parfois il y a comme des arrets...on doit être trop nombreux sur le serveur non ?"...

Je ne dis pas que le GC et Hibernate sont comparables ou que l'un est meilleur que l'autre. Ce sont des produits tellement different.
Je dis simplement qu'ils sont tout les deux le fruit d'une même mouvance : "Focaliser le développeur sur le métier"

PS: le travail que réalise le GC est également énorme, ne te fourvoye pas.

[divxdede]

[*]J'ai suffisament écrit de C et C++ pour savoir que la gestion de la mémoire ne prend pas de temps dev. Ou alors vous allez me dire que l'intialisation des variables aussi vous fait perdre du temps ? [*]Ils passent plus de temps à chercher les fuites que je ne le faisait en C++, encore du fric perdu.

La gestion mémoire (et liberation) est trés differentes d'un langage procédural d'un langage objet. Dans un langage objet, il ne faut pas se rater et liberer un objet encore utilisé par ailleurs. Et j'ai vu tout autant de programmes C++ planter à cause de libération mémoire malencontreuse que des programmes Java pour leur "memory heap size exceeded"

Maintenant je mène un projet J2EE depuis 2.5 ans, évidemment nous avons eux des memory leaks. 2x jours nous on suffit pour supprimer la majeur partie.

J'estime que ce coût n'est pas excessif, et n'est pas exagéré par rapport au temps passé sur des versions C,C++. J'ai connu bien plus de déboire sur la gestion mémoire du temps du C/C++.

[deneb]

La gestion mémoire (et liberation) est trés differentes d'un langage procédural d'un langage objet. Dans un langage objet, il ne faut pas se rater et liberer un objet encore utilisé par ailleurs. Et j'ai vu tout autant de programmes C++ planter à cause de libération mémoire malencontreuse que des programmes Java pour leur "memory heap size exceeded"

Maintenant je mène un projet J2EE depuis 2.5 ans, évidemment nous avons eux des memory leaks. 2x jours nous on suffit pour supprimer la majeur partie.

J'estime que ce coût n'est pas excessif, et n'est pas exagéré par rapport au temps passé sur des versions C,C++. J'ai connu bien plus de déboire sur la gestion mémoire du temps du C/C++.

Tout est dit !
Autant de temps perdu à gérer la mémoire...et ses fuites, avec ou sans GC !

[deneb]

Je ne dis pas que le GC et Hibernate sont comparables ou que l'un est meilleur que l'autre. Ce sont des produits tellement different.Je dis simplement qu'ils sont tout les deux le fruit d'une même mouvance : "Focaliser le développeur sur le métier"

PS: le travail que réalise le GC est également énorme, ne te fourvoye pas.

J'ai jamais dit ça ?
Tu as fait un parallele entre les deux et je te dis qu'il n'est pas correct car même si les deux ont pour but de prendre en charge une partie des tâches compliquées normalement dévolues au developpeur, Hibernate y arrive et me fait gagner de l'argent alors que le GC au mieux ne me rapporte rien, au pire il me fait perdre du temps (de l'argent donc)

[deneb]

Bon allez, on peut continuer à parlez philo si vous le souhaitez, mais il est clair que mon option "no-gc" ne pourra jamais exister.
Tout ça à cause d'une autre hérésie de design de Java : les objects "unmutable" comme le très célèbre String.

Pour les amateurs de C++ qui trainent sur ce sujet et qui ne sont pas familiers de ce concept "avancé" , il s'agit d'un objet dont on est assuré (dans la mesure où il respecte un pattern de construction bien défini) que les valeurs internes ne changeront jamais.
Fort de se principe...on peut se permettre qq hérésies comme ce constructeur de String qui est sensé contruire une nouvelle String avec la valeur d'une autre en argument...
Voila le code (épuré pour ne faire apparaitre que l'essentiel)

Code :

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

1
2
3
4
5
public String(String original) 
{
[...]
	this.value = original.value;
}

Alors là forcement, si on se permet ce genre de blague, il n'y a plus d'autre solution que de laisser Dieu le Père gérer tout seul la mémoire

[divxdede]

A ton avis pourquoi les chaines (String) sont immuables ? ...
Tout simplement pour économiser la mémoire !! et oui.

Car finalement si dans une classe tu écris

Code :

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

  String value = "Bonjour";

Et que par ailleurs tu écris

Code :

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

  String txt = "Bonjour";

Et bien la JVM peut pour optimiser en affectant la meme "réference" (InternalString) aux deux variables car elle sait que la classe String lui garantie que personne ne touchera à son contenu.
Au vue de la profusion de l'utilisation des chaines dans une application, ce type de gestion a son avantage

Je te l'accorde, cela a aussi ses inconvénients

Pour ce qui est du constructeur, la remarque a déja été faite sur le forum Java. Et meme la javadoc du constructeur annonce clairement qu'il ne sert pas a grand chose sauf cas extremement spécifique où on désire une autre instance de la chaine.

[deneb]

C'est vraiment pour économiser de la mémoire qu'on utilise des immuables...et donc un GC...qui entraine un gaspillage de mémoire ?

[deneb]

Just kidding man
Tu cherches à me convaincre ? Pourquoi pas...en tout cas on peut en parler, après tout c'est le coin des débats. On n'est pas obligé d'arriver à un consensus, l'interet c'est de parler du sujet.

Après tout, on peut reprendre la question à la base : A quoi sert le GC ?
Qu'apporte t-il de tangible au développeur ?
- Gain de temps ?
- Gain d'efficacité ?
- Gain de performance ?

Et quels sont les revers de la médaille ?

[divxdede]

Je suis partant meme si te convaincre n'est pas un but en soi. Chacun a droit a ces opinions !! c'etait simplement que ton précedent post avait une certaine propension au "troll"

On peut penser que le GC sert a gerer la libération mémoire à la place du développeur. Ce qui est FAUX !!
Le GC change la méthode de libération mémoire de la part du développeur.

Au lieu de la liberer explicitement (et donc coder ces algos maisons determinant si un objet peut etre liberé), avec un GC on doit simplement "liberer" un objet en arrettant de le referencer lorsque celui-ci n'est plus nécessaire (pour le referant)

Si le developpeur est rigoureux sur ce dernier point, le GC fera son travail aussi bien qu'un developpeur faisant tout a la main.
D'autant plus que nous avons des outils (WeakReference,SoftReference) pour aider le GC a casser les references cycliques et gerer les caches ou pool.

Mais alors quel est l'avantage ?
- La liberation par le GC est fiable: il ne liberera pas un objet qu'il ne fallait pas
- Le développeur pilote la gestion mémoire d'une façon plus "confortable" et n'a pas a mettre en oeuvre tout un tas de mécanisme.

Quel sont les inconvenients ?
- On ne contrôle pas le moment de la libération
- Si on ne "casse" pas les réferences inutiles, on se prends des memory leaks

Le dernier incovenient n'est pas trés "recevable" puisqu'il correponds à un developpeur C ne fesant aucun "free()" aprés des "malloc()". Dans ce cas il faut patcher le développeur pour rattraper le tir ^^

Voila ;o)

[deneb]

Ahh de la matière

Je suis partant meme si te convaincre n'est pas un but en soi. Chacun a droit a ces opinions !! c'etait simplement que ton précedent post avait une certaine propension au "troll"

Ca en était
Parfois il faut bien dire qq conneries. On peut bien se détentre un peu ici ? (on est pas du coté "help me").

On peut penser que le GC sert a gerer la libération mémoire à la place du développeur. Ce qui est FAUX !!
Le GC change la méthode de libération mémoire de la part du développeur.
Au lieu de la liberer explicitement (et donc coder ces algos maisons determinant si un objet peut etre liberé), avec un GC on doit simplement "liberer" un objet en arrettant de le referencer lorsque celui-ci n'est plus nécessaire (pour le referant)

Ok c'est ça que je ne comprend pas! Quels algos fabuleux faut-il inventer ? C'est étrange cette légende selon laquelle il serait compliqué de libérer correctement la mémoire avec un langage sans GC. Moi je ne connais qu'un seul pattern et qui fonctionne à tous les coups (pas qu'en programmation), celui du responsable : "le créateur est responsable de la vie des ses créations". Et il n'y a jamais le moindre problème. Les seules fois où je me suis demandé si je pouvais bien libérer un object c'est qu'à un moment j'avais codé comme un cochon et que j'étais sorti du schéma.

Si le developpeur est rigoureux sur ce dernier point, le GC fera son travail aussi bien qu'un developpeur faisant tout a la main.
D'autant plus que nous avons des outils (WeakReference,SoftReference) pour aider le GC a casser les references cycliques et gerer les caches ou pool.

Aussi bien, mais pas mieux...Tu le souligne toi même, le developpeur Java doit faire preuve d'un grande rigueur s'il ne veut pas voir son heap se réduire comme peau de chagrin. Pour moi cela demande exactement la même attention et le même temps que de gérer proprement ses new/free.

Mais alors quel est l'avantage ?
- La liberation par le GC est fiable: il ne liberera pas un objet qu'il ne fallait pas
- Le développeur pilote la gestion mémoire d'une façon plus "confortable" et n'a pas a mettre en oeuvre tout un tas de mécanisme.

La libération par erreur d'un objet engendre un bug archi facile à repérer puiqu'on a droit généralement à un plantage violent. Un test = bug identifié.
A l'inverse une Map qui accumule des références indésirables, ça ne se voit pas. C'est même le genre de sournoiserie qui ne se manifeste qu'à forte charge quand tous les clients sont connectés...
Je préfère de loin le premier cas.
Ensuite ce que tu appelle du confort est pour moi une incitation à une gestion "laxiste"...Et en regardant le code des mes équipes, je crois bien que j'ai un peu raison sur ce point.

Quel sont les inconvenients ?
- On ne contrôle pas le moment de la libération
- Si on ne "casse" pas les réferences inutiles, on se prends des memory leaks
Le dernier incovenient n'est pas trés "recevable" puisqu'il correponds à un developpeur C ne fesant aucun "free()" aprés des "malloc()". Dans ce cas il faut patcher le développeur pour rattraper le tir ^^
Voila ;o)

On en revient au même point...si tu gère bien, le GC fera bien son boulot.
Mais cette bonne gestion demande exactement la même discipline et le même temps qu'une bonne gestion manuelle.
Sauf qu'à la main, le travail est FAIT et on ne voit pas de GC s'inviter de manière intempestive au moment où on a besoin de CPU.

[adiGuba]

Fort de se principe...on peut se permettre qq hérésies comme ce constructeur de String qui est sensé contruire une nouvelle String avec la valeur d'une autre en argument...
Voila le code (épuré pour ne faire apparaitre que l'essentiel)

Code :

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

1
2
3
4
5
public String(String original) 
{
[...]
    this.value = original.value;
}

Alors là forcement, si on se permet ce genre de blague, il n'y a plus d'autre solution que de laisser Dieu le Père gérer tout seul la mémoire

Ceci est FAUX : le constructeur String(String) est bien un constructeur de copie, et crée bien un nouvel objet totalement différent en mémoire ! D'ailleur c'est indiqué dans la Javadoc : "the newly created string is a copy of the argument string"...


Enfin, les objets immuables permettent une optimisation de la mémoire en évitant des copies d'objets à tout va, comme cela peut être la cas en C++ pour respecter la règles "le créateur est responsable de la durée de vie des objets"...

Ok c'est ça que je ne comprend pas! Quels algos fabuleux faut-il inventer ? C'est étrange cette légende selon laquelle il serait compliqué de libérer correctement la mémoire avec un langage sans GC. Moi je ne connais qu'un seul pattern et qui fonctionne à tous les coups (pas qu'en programmation), celui du responsable : "le créateur est responsable de la vie des ses créations". Et il n'y a jamais le moindre problème.

Ce design pattern te convient peut-être, mais il n'est pas adapté à tous les besoins. Le créateur des objets peut ne pas connaitre la durée de vie exacte des objets, et donc cela complexifie encore les choses...

Aussi bien, mais pas mieux...Tu le souligne toi même, le developpeur Java doit faire preuve d'un grande rigueur s'il ne veut pas voir son heap se réduire comme peau de chagrin.

Grande rigueur : il ne faut pas exagérer... Il faut juste éviter de multiplier les champs static et d'utiliser 500 attributs dans les objets, alors que la plupart des éléments ne servent que temporairement, ou de les mettres à null lorsqu'on n'en a plus besoin... mais c'est une erreur de programmation, pas un défaut du GC...

C'est la même chose qu'un développeur C qui n'utiliserait que des variables globales...

Pour moi cela demande exactement la même attention et le même temps que de gérer proprement ses new/free.

C'est peut-être vrai dans le cas où le créateur est responsable de la durée de vie des objets... mais faux dans des cadres plus complexe où tu dois partager des objets...

La libération par erreur d'un objet engendre un bug archi facile à repérer puiqu'on a droit généralement à un plantage violent. Un test = bug identifié.
A l'inverse une Map qui accumule des références indésirables, ça ne se voit pas. C'est même le genre de sournoiserie qui ne se manifeste qu'à forte charge quand tous les clients sont connectés...

Tu ne compares pas ce qui est comparable... tout simplement parce que la libération par erreur est impossible avec un GC !

Le problème de la Map avec des références indésirables est plus proche d'un oubli de libération de mémoire !
Si tu conserves une Map avec de nombreux objets indésirables, c'est comme si tu ne faisais pas de free() après tes malloc() : c'est une erreur de programmation !

Et dans ces deux cas, il te faudra surveiller la consommation de mémoire de ton application...

Je préfère de loin le premier cas.
Ensuite ce que tu appelle du confort est pour moi une incitation à une gestion "laxiste"...Et en regardant le code des mes équipes, je crois bien que j'ai un peu raison sur ce point.

On en revient au même point...si tu gère bien, le GC fera bien son boulot.

Le GC n'est pas miraculeux : il ne peux pas conserver plus d'objet que sa mémoire ne lui permet... mais personne n'a dit le contraire !

Mais cette bonne gestion demande exactement la même discipline et le même temps qu'une bonne gestion manuelle.

Oh non, la gestion de la mémoire avec un GC demande nettement moins de temps !

Sauf qu'à la main, le travail est FAIT et on ne voit pas de GC s'inviter de manière intempestive au moment où on a besoin de CPU.

Si le GC s'invite à table, cela signifie que ton application utilise trop de mémoire à un moment donnés : dans tous les cas il te faut libérer cette mémoire...


a++

[deneb]

Ceci est FAUX : le constructeur String(String) est bien un constructeur de copie, et crée bien un nouvel objet totalement différent en mémoire ! D'ailleur c'est indiqué dans la Javadoc : "the newly created string is a copy of the argument string"...

Alors là je crois que tu ferais bien de réviser un peu...
C'est une portion (copiée/collée) d'un constructeur de String pris dans le source du JDK 1.5_07.
C'est d'ailleurs assez logique qu'ils procèdent comme ça, puisque l'objet est immuable...On peut se dire que lorsque tout le monde en aura fini avec ce tableau de char, le GC finira bien par le ramasser.
Désolé, c'est une conception qui ne me satisfait pas.

Enfin, les objets immuables permettent une optimisation de la mémoire en évitant des copies d'objets à tout va, comme cela peut être la cas en C++ pour respecter la règles "le créateur est responsable de la durée de vie des objets"...

Les immuables permettent d'économiser des bouts de chandelles. Essentiellement sur des String. Dans une vrai appli il n'y a AUCUN appel du type : String s = new String("toto");
Les chaines sont stockées sur des supports externes (fichiers, bdd,...) et son chargés dans des conteneurs à l'exécution...Dans ce cas je vois pas l'économie.

Ce design pattern te convient peut-être, mais il n'est pas adapté à tous les besoins. Le créateur des objets peut ne pas connaitre la durée de vie exacte des objets, et donc cela complexifie encore les choses...

Je vais pas te citer tous les projets sur lesquel j'ai bossé en plus de 10ans de vie professionnelle (je te fais grâce des 10 précédentes ou je développais en hobbiste, parfois payé). Ce design convient à TOUS les types d'application.
D'ailleurs regarde un peu au tour de toi...en quoi sont écrit 90% des softs que tu utilise ?

Grande rigueur : il ne faut pas exagérer... Il faut juste éviter de multiplier les champs static et d'utiliser 500 attributs dans les objets, alors que la plupart des éléments ne servent que temporairement, ou de les mettres à null lorsqu'on n'en a plus besoin... mais c'est une erreur de programmation, pas un défaut du GC...
C'est la même chose qu'un développeur C qui n'utiliserait que des variables globales...

On tourne en rond...Je te répond que sans GC, il suffit de gérer correctement les new/free. Celui qui réserve libère et puis c'est tout.

C'est peut-être vrai dans le cas où le créateur est responsable de la durée de vie des objets... mais faux dans des cadres plus complexe où tu dois partager des objets...

Je ne vois pas...En matière de complexité un serveur d'application se place sur quelle échelle selon toi ?
Est-ce que le partage d'objets entre plusieurs serveurs te parait une chose compliquée ?
Pas besoin de GC pour faire ça pourtant.

Tu ne compares pas ce qui est comparable... tout simplement parce que la libération par erreur est impossible avec un GC !
Le problème de la Map avec des références indésirables est plus proche d'un oubli de libération de mémoire !
Si tu conserves une Map avec de nombreux objets indésirables, c'est comme si tu ne faisais pas de free() après tes malloc() : c'est une erreur de programmation !
Et dans ces deux cas, il te faudra surveiller la consommation de mémoire de ton application...
Le GC n'est pas miraculeux : il ne peux pas conserver plus d'objet que sa mémoire ne lui permet... mais personne n'a dit le contraire !

Jamais dit le contraire.
Avec ou sans GC il faut faire son taf de développeur.
Là ou mon point du vue diffère du tien, c'est qu'ayant développé très très longtemps en C, pas mal en C++ et finalement encore plus en Java, je SAIS d'expérience que l'effort demandé dans un cas comme dans l'autre est le même.

[adiGuba]

Alors là je crois que tu ferais bien de réviser un peu...
C'est une portion (copiée/collée) d'un constructeur de String pris dans le source du JDK 1.5_07.

Je te renvoit ta remarque, puisque le code exact et complet est le suivant :

Code :

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
    /**
     * Initializes a newly created <code>String</code> object so that it
     * represents the same sequence of characters as the argument; in other
     * words, the newly created string is a copy of the argument string. Unless 
     * an explicit copy of <code>original</code> is needed, use of this 
     * constructor is unnecessary since Strings are immutable. 
     *
     * @param   original   a <code>String</code>.
     */
    public String(String original) {
    int size = original.count;
    char[] originalValue = original.value;
    char[] v;
      if (originalValue.length > size) {
         // The array representing the String is bigger than the new
         // String itself.  Perhaps this constructor is being called
         // in order to trim the baggage, so make a copy of the array.
        v = new char[size];
         System.arraycopy(originalValue, original.offset, v, 0, size);
     } else {
         // The array representing the String is the same
         // size as the String, so no point in making a copy.
        v = originalValue;
     }
    this.offset = 0;
    this.count = size;
    this.value = v;
    }

Il y a bien une copie du tableau de char représentant la String

C'est d'ailleurs assez logique qu'ils procèdent comme ça, puisque l'objet est immuable...On peut se dire que lorsque tout le monde en aura fini avec ce tableau de char, le GC finira bien par le ramasser.
Désolé, c'est une conception qui ne me satisfait pas.

Ce constructeur (à la C++) alloue encore plus de mémoire inutilement...
Si cela ne te sastifait pas, c'est que ce serait trop dur à gérer sans GC...

Les immuables permettent d'économiser des bouts de chandelles. Essentiellement sur des String.

L'économie n'existe pas seulement en ce qui concerne les String puisqu'il existe d'autre classe immuable.

Dans une vrai appli il n'y a AUCUN appel du type : String s = new String("toto");

C'est vrai que c'est totalement inutile... c'est d'ailleurs indiqué dans la doc !

Les chaines sont stockées sur des supports externes (fichiers, bdd,...) et son chargés dans des conteneurs à l'exécution...Dans ce cas je vois pas l'économie.

Si tu as des chances de chargé plusieurs fois les mêmes chaines, tu peux économiser la mémoire en utilisant la méthode intern() qui utilise un cache de String...


Ensuite l'économie de l'immuabilité vient du fait que l'on n'est plus obligé de créer des objets temporaires pour les attributs de nos objet. Par exemple si j'ai une classe qui utilise un attribut de type String, je peux utiliser la même référence sans craindre qu'elle soit modifier de l'extérieur de ma classe par un code du style :

Code :

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

1
2
3
String s = "valeur";
MaClasse maClasse = new MaClasse(s);
s.setValue("nouvelle valeur"); // IMPOSSIBLE

Ainsi, on n'est pas obligé de copier les valeurs des attributs dans le constructeur, et on reste sûr qu'il ne sera pas modifié pour rien...

En C++ le moindre passage d'objet à une méthode implique une copie de l'objet. A moins de passer via les références, mais dans ce cas il faudrait faire une copie explicite pour éviter qu'un attribut ne soit modifié en dehors de la classe...

Les classes immuables sont une notion importante de Java, et peu présente en C++. Cela fait un approche relativement différente de la conception des objets...

Je vais pas te citer tous les projets sur lesquel j'ai bossé en plus de 10ans de vie professionnelle (je te fais grâce des 10 précédentes ou je développais en hobbiste, parfois payé). Ce design convient à TOUS les types d'application.

Je maintiens qu'il n'est pas adapté à toutes les situations et ne permet pas facilement le partage d'objet...

D'ailleurs regarde un peu au tour de toi...en quoi sont écrit 90% des softs que tu utilise ?

Si Java est très peu présent sur le Desktop, ce n'est pas à cause de son GC, mais de la mauvaise réputation que Swing se traine...

On tourne en rond...Je te répond que sans GC, il suffit de gérer correctement les new/free. Celui qui réserve libère et puis c'est tout.

C'est ce que fait le GC : il réserve et il libère

Je ne vois pas...En matière de complexité un serveur d'application se place sur quelle échelle selon toi ?
Est-ce que le partage d'objets entre plusieurs serveurs te parait une chose compliquée ?
Pas besoin de GC pour faire ça pourtant.

Je ne vois pas ce que le GC viendrait faire ici !?!?

Là ou mon point du vue diffère du tien, c'est qu'ayant développé très très longtemps en C, pas mal en C++ et finalement encore plus en Java, je SAIS d'expérience que l'effort demandé dans un cas comme dans l'autre est le même.

L'effort est quand même loin d'être le même...

a++

[duncan55]

Tu es assez buté Deneb.

Je ne connais pas ton parcours ni les types de projet surlequels tu as travaillés mais le théorie "Celui qui créé, détruit" n'est pas toujours applicable même si elle doit être au max respectée.

Il y a beaucoup de types différents de projets et je t'assure que même en étant un développeur C chevronné, les fuites de mémoires peuvent devenir un vrai casse tête dans certains projets et assurer une gestion parfaite de la mémoire (sans fuite de mémoire ni libération abusive) demande tellement de temps que l'utilisation d'un GC s'impose.

Encore une fois, a moins de travailler sur un projet dont la ressource processeur est très très critique, l'éxecution du GC ne ralentit franchement pas.

Je veux bien croire que ce problème peut exister coté serveur (et encore, dans des cas spécifiques) mais coté client j'ai du mal à croire que le GC ralentit la machine. Aujourd'hui les processeurs passent leur temps à attendre les autres ressources et le GC s'insère très bien entre deux appels disque/réseau/utilisateur de ton appli.

[duncan55]

Concernant la question initiale "Pour ou contre le Garbage Collector".

Je répondrais ce que je réponds souvent à ce genre de question : "Ca dépend du projet".

Si c'est un projet "classique" qui ne demande pas à utiliser comme un dingue le processeur, alors le GC sera un plus car il permettera d'améliorer grandement la gestion de la mémoire et de gagner pas mal de temps la dessus.

Si la gestion de la mémoire est très importante dans le projet et qu'il faut impérativement la gérer "à la main", alors ne pas utiliser de GC (ce qui veut dire ne pas coder en Java).

Java n'est pas le meilleur langage, aucun n'est parfait. Il répond à des besoins.
Comme le GC. S'il ne convient pas à un besoin, et bien on ne l'utilise pas et c'est tout !

Pour moi il n'y a pas de choix à faire entre "pour ou contre GC", ca dépend de l'appli. C'est d'ailleurs pour cette raison qu'un developpeur doit connaitre plusieurs langages

[davcha]

Pas besoin de GC pour faire ça pourtant.

J'ai l'impression que deneb se concentre beaucoup sur la question de savoir ce que permet un GC que ne permet pas une gestion manuelle de la mémoire.

A priori, le débat me semble un peu creu, dans la mesure où les langages dignes de ce nom sont turning complet.

La question n'est donc pas de savoir ce qui peut ou ne peut pas être fait, mais plutôt si le GC ou la gestion manuelle de la mémoire permettent de programmer plus "proprement", efficacement.
Encore que "proprement"... Ce terme est suffisamment vague pour que quelqu'un vienne dire que l'utilisation d'un GC n'est pas propre ou inversement que la gestion manuelle de la mémoire peut devenir une usine à gaz, sans pour autant amener d'arguments valables.

Personnellement, je programme principalement en C# et C++.
Je trouve le GC du C# très intéressant, car il augmente ma productivité. Et quand j'ai des parties de code où la gestion de la mémoire est critique (que ce soit pour des questions de perf ou de minimalisations d'utilisation mémoire), je passe en C++, où je gère la mémoire directement, sans GC.

Je vois pas tellement le problème en fait. Il y a des cas où le GC est super, d'autres où une gestion manuelle est préférable...

[deneb]

Tu es assez buté Deneb.

Mais non, j'ai des pb liés au GC alors que je considère qu'il ne m'apporte rien.

Je veux bien croire que ce problème peut exister coté serveur (et encore, dans des cas spécifiques) mais coté client j'ai du mal à croire que le GC ralentit la machine. Aujourd'hui les processeurs passent leur temps à attendre les autres ressources et le GC s'insère très bien entre deux appels disque/réseau/utilisateur de ton appli.

Justement je bosse sur des appli serveur où le temps pris par le GC est pénalisant.