En C++ ce serait la même chose, il serait préfèrable d'utiliser un strstream pour pouvoir profiter d'un buffer.Envoyé par adiGuba
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
En C++ ce serait la même chose, il serait préfèrable d'utiliser un strstream pour pouvoir profiter d'un buffer.
ben moi je ne suis ni pour ni contre, bien au contraire
sérieusement le garbage collector me semble vraiment adapté pour les applications J2EE. Ce genre d'application tourne souvent sur des machines multi-processeurs et justement le GC peut fonctionner en parallèle(ce qui diminue les temps de pause).
De plus depuis j2se 5.0, le garbage collector adapte sa stratégie automatiquement au cours de l'exécution de l'appli. En gros il y a trois points qu'il tente d'optimiser (dans l'ordre je crois): les temps de pause, le vitesse d'allocation, et l'empreinte en jouant sur la taille de l'espace de génération (espace des objets à vie courte).
Les performances du GC se mesurent plutot sur le long terme (justement une appli J2EE peut tourner des jours sans redémarrage).
"Les gens normaux croient que si ca marche, c'est qu'il n'y a rien à reparer. Les ingénieurs croient que si ca marche, c'est que ca ne fait pas encore assez de choses."
--Scott Adams
Un GC, c'est :
- un outil permettant d'éviter d'avoir à ramasser soi-même ses poubelles. Le concept d'éboueur quoi, et il n'y a pas de sous-métier...
- une aide précieuse au développeur qui ne veut pas passer 25% de son temps à penser à libérer ses objets (ce qui ne dispense en aucun cas de déréférencer ceux-ci)
- un outil pas adapté pour du temps réel sur architecture à mémoire très limitée, mais fort utile sur des applications d'entreprise...
Et s'il vous plaît, arrêtez de dire que Java est lent à cause du GC, car :
1- Java n'est plus aussi lent qu'avant (parfois aussi rapide que C++, n'en déplaise à certains)
2- le GC ne s'exécute parfois jamais dans la durée d'une application (sisi...), il ne s'exécute quand il n'y a rien d'autre à faire...
3- OCaml a un GC, et il est très efficace (cf les benchmarks vs C++)
Au final, je tiens à mettre le doigt sur un ptit truc : si la gestion de mémoire explicite était la panacée, pourquoi les "pointeurs intelligents" seraient à la mode en C++ ?
En premier lieu, utilisez un moteur de recherche.
En second lieu, postez sur le forum adéquat !
La faute aux exceptions qui changent la donne par rapport à une approche explicite en C où la règle du Single-Entry Single-Exit (SESE pour les intimes) faisait la loi.
Les exceptions incitent à partir vers le RAII si on veut du maintenable, les smart-pointeur n'étant qu'un cas particulier de RAII appliqué par défaut à la mémoire -- les pointeurs intelligents de boost (collection de bibliothèques C++) sont en fait plus des ressources intelligentes qui peuvent être appliquées sur n'importe quoi.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Dur à accepter...
Deneb,
Grâce au GC tu peux te concentrer sur le métier (Et développer plus vite !!!)
Pour une bonne partie des applications d'entreprise peu importe la manière dont est gérée la mémoire. Personnellement je pense qu'il y a des gars chez Sun suffisamment compétents et qui ont eu largement assez de temps pour étudier la question en profondeur. En tout cas bien mieux que je ne le ferais moi même. Et grâce à leur travail je peux me concentrer sur l'essentiel : le business.
Alors évidement si tes ressources sont extrêmement critiques un GC n'est pas la meilleure des solutions. Mais elle à le mérite de proposer un standard de prog qui satisfait la plupart des cas.
Enfin si tu est tellement convaincu que la GC est une hérésie, Sun n'attend que toi pour révolutionner la JDK et supprimer çà pour la version 7:
https://jdk7.dev.java.net/collaborate.html
https://jdk6.dev.java.net/collaborate.html
De toute facon ce débat est forcement un troll puisque il faut déjà savoir si l'on discute d'informatique des systèmes d'information ou alors d'informatique temps réelle et embarquée. Les besoins ne sont pas comparables.
La où la ressource mémoire est limitée et figée, la gestion de la mémoire doit être fine. Il est alors en effet préférable de laisser le développeur gérer finement l'utilisation de la mémoire.
Pour les SI, la mémoire est "abondante". On se concentre sur les problématiques métiers et la tendance est de déléguer un maximum de travail (persistance, sécurité, transaction, et ... gestion de la mémoire !) à un framework ou à un middleware.
De manière générale, l'ingénierie des systèmes d'informations cherche à monter en abstraction depuis des années (ex: récemment, l'ingénierie des modèles). La gestion de la mémoire est une préoccupation de bas niveau qui n'interesse plus grand monde dans ce milieu.
Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS
Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android
Plutôt d'accord avec Hephaistos007.
Le GC c'est bien quand tu as suffisamment de ressources pour ne pas avoir à t'en occuper.
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
...le tout étant de ne pas se dire que l'on peut ne pas faire du tout attention à la mémoire sachant qu'il y a un GC. Il ne faut pas faire n'importe quoi (cf l'exemple de la boucle avec concaténation via l'opérateur +).
Donc grosso modo, débat résumé en deux ou trois posts
"En essayant continuellement, on finit par réussir. Donc : plus ça rate, plus on a de chances que ça marche" (devise Shadock)
Application :
ainsi qu'à regarder la
avant de poser une question.
La rubrique Perl recrute, contactez-moi.
Il serait peut-être plus intérressant de donner des exemples de cas où on atteint les limites du GC...
non ?
- J2ME, le lancement du GC demande des ressources, il impose aux developpeurs de s'assurer que le produit embarqué aura toujours les ressources nécessaire à l'execution du gc() sous peine de crasher la hot spot. La mémoire est un élement souvent critique en ce qui concerne les produits embarqués (même si c'est de moins en moins vrai)
- Avec une grappe d'objet formant un grpahe cyclique d'une taille énorme. Le gc() va mettre énormement de rounds (voir jamais) pour determiner que tout ces objets sont "libérable". A ce stade, j'en conviens... ce n'est pas rééllement un problème liée au gc() mais à la programmation.
- Application RT. le lancement d'un gc() n'est que trop rarement prédictif (en java c'est impossible)
A n'en déplaise, je suis un partisan du gc(), mais ces differents arguments ont tous déja été dit. Ils le seront a nouveaux. et je ne vois pas d'avancée dans ce débat qui tourne en rond.
JBusyComponent, une API pour rendre occupé un composant swing.
SCJP Java 6.0 (90% pass score)
Moi, l'exemple que je trouverais intéréssant, c'est la saturation des serveurs avec 4 GO de ram là où un serveur avec 10MO aurait suffit sans GC
Plus sérieusement, les exemples oint déjà été donné, maintenant on le trouve valable ou non.
"En essayant continuellement, on finit par réussir. Donc : plus ça rate, plus on a de chances que ça marche" (devise Shadock)
Application :
La rubrique Perl recrute, contactez-moi.
J'ai sans doute forcé un peu le trait mais on n'est pas si loin que ça de la réalité. Le cas typique qu'on a ici concerne le multithreading.
Chacun sait (enfin ceux d'entre vous que les problèmes de mémoire intéressent encore
A ce compte là, la mémoire occupée monte à vitesse grand V...et sature notre beau serveur avec ses 4 Go de RAM.
Aujourd'hui on a une nouvelle version, beaucoup plus complexe il est vrai, mais dont chaque thread prend en charge plusieurs request en // et qui ne consomme plus rien...tout allant plus vite.
Sinon vous pouvez fermez le sujet il ne reste plus grand chose à en dire.
Moi je concluerais par le fait que beaucoup ne savent pas programmer proprement sans laisser trainer ses affaires et que pour ceux là il faut un GC (et un mec derriere pour leur éviter de tomber dans les gros pièges du GC).
Pour les autres il manque juste deux choses à Java.
Et comme tout est pour le mieux dans le meilleur des mondes, les deux sont à l'étude chez Sun...et c'est bien
- Une méthode System.release(ref) pour forcer le GC à libérer MAINTENANT un graphe d'objets.
- La possibilité de définir des allocations dans la pile.
c'est peu etre un peu hors sujet, mais plutot que de se demander GC ou pas on peux aussi se posé la question allocation dynamique ou pas, non?
En effet la source du probleme c'est bien l'allocation dynamique qui selon moi doit etre utilisé avec la plus grande attention. Si l'on ne fait que tres peu d'allocation dynamique alors on peu se permettre une plus grande rigueur quant a sa gestion et la question du GC devient obsolette. Ceci dit je ne sais pas si cette remarque est pertinente en java et ou en C++.
C'est une bonne remarque...
Quand on développe en C, voir C++ on se pose toujours la question de la durée de vie des espace alloués et en général on essaye de reserver de manière statique tout ce qui peut l'être.
Malheureusement les développeurs Java perdent tous cette bonne habitude et balancent du new à tout va juste au moment où ils ont besoin d'espace.
C'est l'effet pervers de la perte de responsabilité...
Il faut dire que Java et .Net font la distinction entre type valeur et type référence. Un "type référence" est forcément alloué sur le tas, alors qu'un type valeur peut être sur la pile ou encapsulé dans un type référence.
La différence entre Java et .Net, c'est que java ne permet pas de définir des types valeur complexes...
Et en .Net, je ne sais pas si les types valeur peuvent avoir un destructeur...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je suis le seul à avoir l'impression que cette remarque concernant les thread n'a rien à voir avec le GC mais plutôt avec la compétence du programmeur ?...
je ne suis pas certain qu'un type référence dont tu parles soit alloué sur le tas directement vu qu'en .NET on n'accède pas directement à la mémoire mais via le Framework..
je ne conseillerais pas de faire des analogies avec des langages compilés en code natif
Et puis je me demande si en .NET ou Java lorsqu'on déclare par exemple int ma_variable en fait notre ma_variable devient un VARIANT comme en Visual Basic 6
Je parlais du Tas managé...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Ok il fallait préciser alors
C'est lié !
Un développeur, même très bon, mais qui n'a jamais développé dans un autre language que Java, n'acquiers pas les bons reflexes.
J'ai aussi vu de bons développeurs très expérimentés faire des bourdes plus graves encore (moi le premier), car quand on passe à Java, petit à petit on ne se pose plus la moindre question : on fait comme certains l'ont très bien dit : "confiance aux mecs de Sun qui ont du bien bosser pour que je puisse me consacrer uniquement au métier".
Le problème c'est qu'un jour ou l'autre, tout ce que tu n'as pas vraiment géré et prévu te revient dans la tronche violemment.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager