j'aimerais savoir si écrit proprement n'importe quel truc en java ne finis pas irrémédiablement par bouffer toute la RAM
Non.
ca bouffe la RAM pourquoi ?
Je vais te donner trois pistes mais on pourrait en parler des heures:
1- C'est un langage à GC sans compteur de référence. Tu as un truc qui va ramasser les zones mémoires inutilisées quand il y a besoin. C'est à dire que tu lui donnes une taille maximale et qu'il va commencer à ramasser sérieusement quand il s'approche de cette taille. Avant il s'en balance (tout cela se configure assez finement mais est rarement fait en dehors des grosses archis). Ce mode de fonctionnement n'est pas un problème pour le marché auquel se destine la plateforme. C'est fait pour tenir la prod et tu vas sizer pour que la RAM allouée à la VM corresponde à la taille de son working-set et basta. Ca gache un peu mais pas énorme. C'est beaucoup plus problématique pour les autres usages. Pour un IDE tu ne vas pouvoir le configurer finement et tu vas devoir viser large. Du coup tu as une consommation mémoire qui va finir par rejoindre le pire cas. Ainsi ton eclipse va certainement être livré avec un configuration à 1Go pour être safe alors que tu peux certainement lui en donner que 300Mo.
2- C'est un langage objet dont les devs remettent très rarement en question ce paradigme et se reposent énormement sur les libs quelque soit le cas. Or il peut être très couteux tu peux arriver à des overhead mémoire de malades.
Tu as une veille étude là mais les moeurs n'ont pas changés depuis. Même chose côté CPU; ca m'arrive fréquement de mettre des speedup > 100x en sortant mon profiler et en codant des choses simples. Ce n'est pas un problème du langage ou de la plateforme mais des devs.
3- Framework bloat et paresse, et incompétence de beaucoup de devs. La encore c'est du au fait que c'est juste le langage utilisé.
Maintenant quand tu l'utilises correctement en branchant ton cerveau pour des choses adaptées ca marche bien et c'est un bon outil dans la palette de solutions qui existent. Ca marche très bien dans de nombreux domaines pour beaucoup de monde avec des éxigeances et des compétences.
Maintenant j'irais pas refourger ca pour un jeu, une appli desktop ou quelqu'un qui s'adresse à des mecs qui veulent auto-heberger un service sur 32MB de RAM…
pourquoi ya trop de version de JVM (et sous windows trop de JVM)
Trop je ne sais pas. Pourquoi il y en a plusieurs c'est simple. Tout l'important se fait à l'exécution, la phase de compilation vers le bytecode ne fait presque rien. Du coup la bataille se fait sur la JVM. Du coup c'est comme dire qu'il y a trop de compilateurs C.
Maintenant y'en a pas dix non plus et encore moins pour les usages simples.
pourquoi systématiquement la plupart annonce => OpenJDK pas supporté
Par ce qu'ils ne veulent pas faire l'effort de QA pour valider et supporter OpenJDK. Tout comme beaucoup diront seulement RH supporté.
OpenJDK a aussi eu des problèmes sur la pile graphique et son. Je ne sait pas si c'est résolu c'est pas mon domaine.
[^] # Re: vive Grails
Posté par ckyl . En réponse au journal Epsilon, un outil de gestion de dépense. Évalué à 6.
Non.
Je vais te donner trois pistes mais on pourrait en parler des heures:
1- C'est un langage à GC sans compteur de référence. Tu as un truc qui va ramasser les zones mémoires inutilisées quand il y a besoin. C'est à dire que tu lui donnes une taille maximale et qu'il va commencer à ramasser sérieusement quand il s'approche de cette taille. Avant il s'en balance (tout cela se configure assez finement mais est rarement fait en dehors des grosses archis). Ce mode de fonctionnement n'est pas un problème pour le marché auquel se destine la plateforme. C'est fait pour tenir la prod et tu vas sizer pour que la RAM allouée à la VM corresponde à la taille de son working-set et basta. Ca gache un peu mais pas énorme. C'est beaucoup plus problématique pour les autres usages. Pour un IDE tu ne vas pouvoir le configurer finement et tu vas devoir viser large. Du coup tu as une consommation mémoire qui va finir par rejoindre le pire cas. Ainsi ton eclipse va certainement être livré avec un configuration à 1Go pour être safe alors que tu peux certainement lui en donner que 300Mo.
2- C'est un langage objet dont les devs remettent très rarement en question ce paradigme et se reposent énormement sur les libs quelque soit le cas. Or il peut être très couteux tu peux arriver à des overhead mémoire de malades.
Tu as une veille étude là mais les moeurs n'ont pas changés depuis. Même chose côté CPU; ca m'arrive fréquement de mettre des speedup > 100x en sortant mon profiler et en codant des choses simples. Ce n'est pas un problème du langage ou de la plateforme mais des devs.
3- Framework bloat et paresse, et incompétence de beaucoup de devs. La encore c'est du au fait que c'est juste le langage utilisé.
Maintenant quand tu l'utilises correctement en branchant ton cerveau pour des choses adaptées ca marche bien et c'est un bon outil dans la palette de solutions qui existent. Ca marche très bien dans de nombreux domaines pour beaucoup de monde avec des éxigeances et des compétences.
Maintenant j'irais pas refourger ca pour un jeu, une appli desktop ou quelqu'un qui s'adresse à des mecs qui veulent auto-heberger un service sur 32MB de RAM…
Trop je ne sais pas. Pourquoi il y en a plusieurs c'est simple. Tout l'important se fait à l'exécution, la phase de compilation vers le bytecode ne fait presque rien. Du coup la bataille se fait sur la JVM. Du coup c'est comme dire qu'il y a trop de compilateurs C.
Maintenant y'en a pas dix non plus et encore moins pour les usages simples.
Par ce qu'ils ne veulent pas faire l'effort de QA pour valider et supporter OpenJDK. Tout comme beaucoup diront seulement RH supporté.
OpenJDK a aussi eu des problèmes sur la pile graphique et son. Je ne sait pas si c'est résolu c'est pas mon domaine.