Discussion :

[neo.51]

Moi je suis biensur pour l'utilisation d'un GC dans la majorité des dev.

Certes ce n'est pas adapté à tous les types de projets mais depuis le temps s'il y avait une techno ou un langage qui convenait à tout type de projet ça se saurait

Tout d'abord je ne suis absolument pas d'accord quand je lis : "avec le GC on doit quand même faire attention à sa mémoire alors autant gérer toute la mémoire par le code de A à Z".
La gestion correcte de la mémoire en C++ demande la mise en place de patherns spécifiques, de l'expérience, du temps et pas mal de réflexion en amont sur un gros projet.
Quand on utilise un GC c'est assez simple : je casse les références entre les objets que je n'utilise plus.

Quand je lis que le GC "débarque" et fait exploser le CPU, je trouve que certain en font un peu trop . Dans la majorité des cas la libération de la mémoire se fait de manière transparente en utilisant trés peu de ressources processeur car la priorité du GC est trés faible. Donc à moins d'avoir une applis sur un serveur qui pousse les ressources systèmes dans ses retranchement je n'ai jamais vu de ralentissement flagrant d'applis à cause du GC collect.

Ce qui peut faire peur c'est la consomation mémoire d'une applis qui peut sembler excessive, mais en fait les GC allouent souvent plus de mémoire que nécéssaire afin d'éviter de faire beaucoup de petites réallocations. En .NET si le système à besoin de mémoire il peut même demander au GC de libérer ce qu'il à alloué mais qu'il n'utilise pas.

En .NET on peut forcer le GC à passer avec la commande GC.Collect().

Forcément une utilisation abusive n'est pas conseillée mais ça permet de voir l'impact qu'a le passage du garbage collector sur les performances de l'applis. Franchement pas de quoi paniquer, quand mon anti-virus se met à jours automatiquement ça me consomme plus de ressources sur mon pc

Alors aprés je dis pas que ce qui ont énormément d'expérience en C++ avec leurs paterns tout pret vont pas forcément gagner du temps avec l'utilisation d'un GC.

Mais pour une écrasante majoritée des développeurs le GC apporte une certainne sécurité au niveau de la gestion de la mémoire (optimisation, gestion des ressources, sécurité du code). Comme avec toutes les technologies il ne faut pas faire n'importe quoi avec mais le GC permet de plus réfléchir à l'architecture et au code métier sans ce soucier de la mémoire.

C'est d'ailleur la tendance du moment la partie "système" (mémoire, processeur, os, ...) ne doit plus préocuper le développeur. Java et .NET ou globalement le code managé doit permettre de faire abstraction du système cible.

Certes si on veut absolument les meilleures performances possibles il faudra toujours resté proche du système mais ça a un coût. Le GC fait gagner du temps et le temps c'est de l'argent. Alors si je peux faire avec un GC je fais avec

[zais_ethael]

Temps de dev, temps de dev ...
Un GC ne fait rien gagner du tout en temps !

L'éternelle question qui oposera toujours les développeurs C++ aux développeurs java. Comme je l'ai dit le GC est une nécéssité technique à un choix de design: le full objet. Le vrai débat est donc de déterminer si un langage full objet est plus rapide à programmer qu'un langage qui ne l'est pas. Qui lance un sondage?

Il y a effectivement des quantités d'API C++, beaucoup plus qu'en Java !
MAIS ce ne sont pas des API standard et c'est ça qui fait toute la différence.

La stl existe depuis fort longtemps, si tout le monde avait jugé utile de batir ses apis la dessus ils l'auraient fait. Mais voila, au vu des nombreuses écoles de pensée qui s'oposent sur la façon de programmer en C++ ca en contente certain et d'autres pas. D'où le fait qu'une grosse partie des librairies réinventent systématiquement la roue même pour de simples... chaines de caractères . Tandis qu'en java il n'y a probablement pas 1000 façons de les gérer ces fameuses chaines, donc tout le monde garde l'implémentation par défaut, et c'est pareil pour tout le reste.

[FremyCompany]

Temps de dev, temps de dev ...
Un GC ne fait rien gagner du tout en temps !

C'est faux, archi faux, ca en fait gagner plein...

Et puis, gerer ta mémoire sans GC, ca te rajoute des lignes de codes en plus et donc ca rend le code moins lisible...

[deneb]

[...]C'est d'ailleur la tendance du moment la partie "système" (mémoire, processeur, os, ...) ne doit plus préocuper le développeur. Java et .NET ou globalement le code managé doit permettre de faire abstraction du système cible.

Et c'est comme ça qu'on arrive à saturer des serveurs avec 4Go de RAM là où en faisant un minimum attention on pourrait se contenter de 10 Mo !
Ne vous marrez pas, c'est du vécu, et pas avec des développeurs pequenots !

Certes si on veut absolument les meilleures performances possibles il faudra toujours resté proche du système mais ça a un coût. Le GC fait gagner du temps et le temps c'est de l'argent. Alors si je peux faire avec un GC je fais avec

Pour bien profiter d'outils qui font gagner du temps de dev, il faut savoir parfaitement comment ils marchent et ce qui se passe dessous sous peine de consommer énormément de ressources.
Un exemple typique lié au langage Java avec sa gestion de mémoire automatique, son GC....(bref rien à faire pour le dev): l'allocation d'objets temporaires dans une boucle.
Le-dis objet n'est stocké nulle part, juste utilisé dans la boucle....(tiens ça me rappelle l'exemple d'Adi en page 1)....et personne ne se pose de question.

Alors évidemment quand je me pointe avec mes gros sabots pour rappeler à tout le monde que la mémoire ça se gère...bah on passe un temps dingue à chasser les allocations dans les boucles et autres joyeusetés coutumières des développeurs Java.

[Luc Hermitte]

Je suis d'accord sur le fait que Java ne soit pas 100% Objet (mais quel langage l'est vraiment ?), mais je ne vois pas en quoi le 1.5 l'est encore moins ???

Je faisais juste allusion au fait que l'introduction d'un nouveau paradigme non objet "nuit" à la pureté OO. Mais honnêtement, la pureté OO n'a pas la moindre importance, d'autant que ce "nouveau" paradigme apporte de la qualité.

> Des GCs
L'éternelle question qui oposera toujours les développeurs C++ aux développeurs java.

Je ne suis pas d'accord. Il y a quantité de développeurs C++ qui utilisent des GC en C++ -- j'ai presque envie de dire qu'ils avaient commencé bien avant l'apparition du Java.
De plus, dans les archives de news:comp.lang.c++.moderated vous trouverez quantité de discussions des plus intéressantes sur les GC. (gurus inside).

[deneb]

Je faisais juste allusion au fait que l'introduction d'un nouveau paradigme non objet "nuit" à la pureté OO. Mais honnêtement, la pureté OO n'a pas la moindre importance, d'autant que ce "nouveau" paradigme apporte de la qualité.

Je ne suis pas d'accord. Il y a quantité de développeurs C++ qui utilisent des GC en C++ -- j'ai presque envie de dire qu'ils avaient commencé bien avant l'apparition du Java.
De plus, dans les archives de news:comp.lang.c++.moderated vous trouverez quantité de discussions des plus intéressantes sur les GC. (gurus inside).

Exact !
J'ai bossé en 97 sur un très gros soft (de modeling 3D) qui utilisait un GC maison. Il faisait d'ailleurs déjà l'objet d'un gros débat en interne !
En ce qui concerne la pureté OO, c'est une bonne chose de s'en écarter sans scrupules quand il le faut. L'objet pur permet de rendre le développement plus consistant (pas forcement plus simple d'ailleurs), mais au détriment des performances. Vous imaginez le bouzin si les types primitifs disparaisaient au profit des seules classes Integer, Float, ...

[nyal]

Si on parle de GC on parle de gestion de mémoire. Qu'est ce que vous pensez de la possibilité de fonctionnement des tâches sous hurd au niveau mémoire ? Il est ainsi possible de réaliser une gestion de mémoire "personnalisée". Je ne connais pas très bien ce sujet.

[outs]

Vous imaginez le bouzin si les types primitifs disparaisaient au profit des seules classes Integer, Float, ...

Il y a des langages comme smarteiffel qui s'en sortent très bien avec des objet comme classes primitives. Et il y a aussi un GC pourtant les programmes smarteiffel sont connu pour leur rapidité comparable a celle des programmes C++ ...

[Woufeil]

Il y a des langages comme smarteiffel qui s'en sortent très bien avec des objet comme classes primitives. Et il y a aussi un GC pourtant les programmes smarteiffel sont connu pour leur rapidité comparable a celle des programmes C++ ...

Ne connaisant pas l'Eiffel je vais peut être dire une bêtise, mais ça doit être un beau bordel pour passer un paramètre par valeur, je me trompe ?

[neo.51]

Et c'est comme ça qu'on arrive à saturer des serveurs avec 4Go de RAM là où en faisant un minimum attention on pourrait se contenter de 10 Mo !

n'en fait pas trop tu vas perdre toute crédibilitée

Pour bien profiter d'outils qui font gagner du temps de dev, il faut savoir parfaitement comment ils marchent et ce qui se passe dessous sous peine de consommer énormément de ressources.

Ben tout nouvel outil est censé faire gagné du temps mais demande un temps de formation et d'assimilation. Quelqu'un qui ne s'occupe pas de la gestion mémoire fera un code pire en c++ qu'avec un GC et apprendre à gérer la mémoire mettra plus de temps en C++ qu'avec un GC... et je parle pas du temps de mise en place.

[davcha]

Vous imaginez le bouzin si les types primitifs disparaisaient au profit des seules classes Integer, Float, ...

http://msdn.microsoft.com/library/fr...iltintypes.asp

[Médinoc]

Mais en .Net, ce sont des types valeur.
En Java, tous les types non-primitifs sont des types référence.

[outs]

Ne connaisant pas l'Eiffel je vais peut être dire une bêtise, mais ça doit être un beau bordel pour passer un paramètre par valeur, je me trompe ?

Non il y a les objets par référence et par valeur. Par défaut les objet sont par référence (l'inverse de C++ quoi) il suffit de rajouter un mot clef (extended) pour les utiliser par valeur, soit cas par cas soit dans toutes utilisation d'un classe. Les types primitifs sont bien sur extended par defaut.

C'est un concept très important pour un langage objet, et presque indispensable si on veut les type primitifs en objet ... <troll>ca existe pas en Java évidement</troll>

Évidement il n'y pas d'allocation mémoire donc ce n'est pas à gérer par le GC

[rige47]

Bonjour à tous,

En prélude je vais dire que je développe, depuis que je suis sorti de l'école (2001), quasiment exclusivement en Java .

Je peux comprendre les frustrations qu'entrainent une gestion de la mémoire par le GC pour ceux qui veulent TOUT gérer eux même, soit pour des raisons techniques ou philosophiques

J'ai lu une bonne partie de ce thread et je ne vais pas répetter ce qui a été dit (je suis pour l'utilisation du GC). Je voulais seulement insister sur le fait que, à mon sens, la proportion de développement qui nécessite réellement une gestion de la mémoire aux petits oigons doit être vraiment ridicule et que peut être dans ces cas là c'est l'utilisation du java comme langage qui n'est pas appropriée.

Je rajoute aussi, comme beaucoup l'ont fait, qu'une bonne programmation est de toute façon nécessaire si on veut avoir qques chose de propre et que si GC il y a, on doit en tenir compte en codant.

++ Fred.

[joseph_p]

Je suis assez perplexe sur les précautions à prendre pour coder en "considérant le GC". En effet, si on lit ce thread http://www.theserverside.com/news/th...hread_id=41857 on découvre plein de choses sur le GC et la JVM.

On apprend que, par exemple, la JVM via les hots spots est à même de détecter que l'utilisateur crée inutilement des objets à l'intérieur d'une boucle et donc de corriger la chose.

Au final, je me demande un peu ce qu'un développeur doit se poser comme question par rapport au couple JVM/GC. Vous avez des pistes ?

La seule que je vois est d'avoir une architecture bien pensée (choisir le bon algo de tri, limiter les lectures/écritures de fichiers et ce genre de choses), mais là ça à peu à voir avec le langage en lui même.

Faut il oui ou non se poser des questions du point de l'optimisation locale du code ?

Merci d'avance

EDIT : correction syntaxique

[adiGuba]

Faut il oui ou non se poser des questions du point de l'optimisation locale du code ?

Cela sort un peu du cadre du DC, mais personnellement je ne me pose pas de question d'optimisation lors du codage, mais seulement lors des tests si je rencontre des problèmes de performance : ca ne sert de se prendre la tête pour optimiser du code alors que le(s) compilateur(s) (normal et "just in time") le font généralement à ta place.

Maintenant il y a toujours des "antipatterns" qu'on apprend à connaitre et qu'on évites de faire, comme le code suivant :

Code :

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

1
2
3
4
String s = "";
while ( /* condition */ ) {
    s += valeur;
}

Qui produit un grand nombre d'objet temporaire (2 par itération) dû à l'immuabilité de la classe String, alors qu'on peut directement utiliser un StringBuffer/StringBuilder !

a++

[zais_ethael]

Early optimisation is the root of all evil
Je l'avais pas ressorti depuis un temps et la ca colle très bien
Non, franchement je ne comprends pas ou est le problème. Depuis que je suis ce thread j'entends vraiment des choses étranges.
"Ca explose la mémoire" - n'importe quoi.
Je sors d'un projet web en java, à certains endroits j'avais calculé que je pouvais créer dans les 1000 objets pour les supprimer une dizaine de lignes plus loin. D'autres listes du même style ainsi que le contenu des formulaires était entièrement stocké en mémoire jusqu'à déconnexion du client (après 30 minutes). Et pourtant, je n'ai jamais constaté de ralentissement, ca tournait impecable sur mon athlon 2000 512 de rams (la config de destination était un bi-pro intel avec 1Go - une base classique pour un serveur de nos jours). Je n'ai jamais constaté plus de 80 mégas d'occupation mémoire (le serveur étant visiblement configuré pour la réserver par pallier de 40M) même dans les procédures de test. Par contre, point de vue architecture c'était ultra simple à gérer. Alors franchement, quand on me dit des choses pareilles je me marre.
Ou alors j'aimerais vraiment que quelqu'un me rapporte une expérience vécue du style:
- type d'application
- son utilité
- database
- les circonstances du problème
Les boucles infinies ne comptent pas

[vbrabant]

Un lien intéressant
http://java.sun.com/j2se/reference/w...whitepaper.pdf

(désolé si déjà mentionné. Je n'ai fait que survoler le débat)

[joseph_p]

l'immuabilité de la classe String, alors qu'on peut directement utiliser un StringBuffer/StringBuilder !

Hotspot ne sait pas gérer ce genre de situations simples ?

[adiGuba]

Un lien intéressant
http://java.sun.com/j2se/reference/w...whitepaper.pdf

Ca à l'air intérressant en effet... il faudra que j'y jette un coup d'oeil quand j'ai le temp

Hotspot ne sait pas gérer ce genre de situations simples ?

Ce est une situation simple : tu lui demandes de créer une nouvelle chaine à chaque itération et c'est ce qu'il fait.
C'est typiquement une erreur de programmation qui surcharge le GC de travail...

a++