Envoyé par
pcdwarf
Ok, cette référence est obsolète mais je maintient l'idée qui est derrière.
à savoir qu'en pratique si tu ne déploies pas le soft sur exactement la même jvm que celle qu'a utilisé le developpeur de l'appli, la proba de couacs est assez élevée.
Je suis davantage admin sys que developpeur.
Les applis, je les développe pas. Par contre, j'en ai déployé un paquesson.
Et je sais sur lesquelles je perds le plus de temps : précisément sur celles programmées avec un langage "haut niveau" tel que java (et dans une moindre mesure python).
Normal ou pas, et lié aux spécificités du langage ou pas, dans la pratique, "application java" = 95% de chances pour que ça ne fonctionne pas du premier coup avec la conf par défaut. et 30% de chances de tomber sur un problème extra-terrestre insoluble.
Et après avoir épluché des stack d'erreur kilométriques, il faut généralement se cogner de fichiers de conf en xml tout aussi kilométriques pour avoir une petite chance d'y arriver.
Je t'assure que j'ai des applications (tierces dont j'ai pas les sources) qui *ne marchent pas* (ou pire : qui plantent au bout de quelques heures) sur des JVM 64 bits.
Pourquoi? j'en sais rien!
Je suis tout a fait d'accod avec toi sur le principe que ça "devrait" rouler tout seul. Mais en pratique, c'est souvent un fail.
Et ce qui est sûr, c'est que quand ça plante à 3H du mat et que t'es d'astreinte, c'est chiant.
Alors du C++, j'en fais. Et je sais qu'on est obligé de gérer la mémoire et que la moindre erreur conduit à des merdes innomables. Ceci étant posé et vu l'usage mémoire que font la plupart des appli faites en java, je pense qu'il doit y avoir pas mal de devs qui font juste confiance au GC pour nettoyer leur merdier. (note que c'est pareil avec tout ce qui ressemble de près ou de loin à des "smartpointers").
Alors ça, c'est réellement le problème. Il faut le paramétrer. Selon moi un programme devrait utiliser autant de mémoire qu'il a BESOIN en veillant à être relativement économe. Mais pas autant qu'on lui en donne.
Disons que c'est une logique que je peux comprendre dans certains contextes quand c'est une statégie de performances. Par exemple, en PHP où on a généralement des process éphémères, il est inutile de perdre du temps à désalouer objet par objet, parce-qu'on épuisera probablement pas la mémoire avant la fin du script et qu'à ce moment là, on pètera tout le processus d'un coup, ce qui est au final un gain de temps CPU considérable. C'est seulement si jamais on tape la limite mémoire, qu'on se paie une séance de GC bien lourdingue.
Ensuite, en pratique, à chaque fois que j'ai essayé de restreindre des jvm à des quantités de RAM qui me semblaient raisonnables vis à vis du travail accompli par l'appli en question, ça s'est mal passé.
Bref, l'écosystème java pose des emmerdes spécifiques. Et c'est ça que j'aime pas.
Partager