Discussion :

[joseph_p]

Statuer clairement sur ta position est très appréciable pour le lecteur, on comprend mieux tes réponses et on se demande moins si tu donnes dans l'hypocrisie. Merci donc. Après on peut se demander de la pertinence d'avoir lancé un tel débat sur le GC si tu es sûr de ne pas changer de position. Ca peut donner l'impression que les gens donnent des arguments pour ou contre le GC dans le vide que la conclusion est déjà là, dommage non ?

Au delà, il y a aussi des langages autre que le Java, même si je suis d'accord qu'on a po toujours le choix dans son taff, en dehors on peut s'pencher sur des choses plus plaisantes histoire de ne pas s'prendre la tête avec des choses qu'on aime po.

Quoiqu'il en soit, proposer des améliorations peut aussi être une très bonne chose, clairement. Mais dans ce cas là autant le dire clairement dans le sujet du topic, se renseigner plus en avant sur la question, en parler autour de soi et enfin aller poster des RFE/JSR bien construites là où il faut. Sinon c'est stérile. Autrement ça peut bouger et plus vite qu'on ne le croit, cf l'histoire de Java Browser Edition, avec le gars qui a lancé l'idée maintenant employé chez Sun !

[deneb]

Je n'ai évidemment pas l'intention de faire avancer le monde en lançant ce débat (d'ailleurs c'est un modérateur qui l'a lancé pour moi en prenant un post sur un autre sujet, mais il a bien fait ).
Je trouve que Java est un très bon language, que la JVM est une idée lumineuse, mais que le GC est une erreur (c'est mon point de vue).
Alors je pose la question pour voir si je suis le seul fou à préférer faire ce boulot à la main où s'il y en a d'autres comme moi .
Donc on en parle, on papote, on argumente...comme on pourrait parler de politique à la fin d'un repas un peu trop arrosé.
Rien de révolutionnaire ne sortira de ce sujet, pas plus que sur "Java vs C++", mais ce qui m'interresse c'est de voir comment les développeurs perçoivent ce type de problème. Est-ce qu'ils ont encore le gout de gratter sous le vernis, comme on faisait avant (chantonnez un peu de Cabrel ici), ou est-ce qu'il préfèrent ne pas trop se faire chier avec ce qui se passe dessous...

[the-gtm]

Le problème que je constate surtout c'est le développeur qui a des a priori et qui fait des "optimisations" sans vérifier que le programme final tourne effectivement plus vite. Du genre parcourir un tableau en sens inverse for (int i=N; i>=0; i--) ou bien déclarer une méthode final pour "aider" la JVM ...
Au final ça donne du code pourri et souvent même plus lent. Dans 90% des cas, l'essentiel est d'avoir un bon design (pour avoir qq chose de maintenable) et de faire gaffe aux opérations forcément couteuses (réseau, fichiers, GROSSE allocation, threads ...)

Le coup du new Point() dans une méthode, ok c'est pas top mais au final le coût est extrêmement faible. Alors si ça rend le code plus lisible et plus maintenable ça me va (je ne sais pas si c'était le cas dans l'exemple donné).
Avec les JVM récentes l'allocation se fait "comme sur une pile" et ne coûte donc quasi rien, de même que la désallocation. Alors vouloir faire des free et des malloc pour "aider" l'ordinateur n'est pas forcément une bonne idée. La plupart des développeurs ont une compréhension limitée de ce qu'est réellement un GC (je m'inscris dans le lot ) et colportent des rumeurs à ce sujet.

Pour y voir un peu plus clair, c'est assez bien expliqué ici

Le seul truc en lequel je crois c'est ratio entre le coût de développement et la performance finale de l'application. Suivant le point où est mis le curseur on prend des experts assembleurs qui vont faire un truc hypra optimisé ou bien des junior VB qui font faire un veau mais pour un coût faible (ou bien entre les deux la plupart du temps )

"Early optimization is the root of all evil."

[davcha]

Il est très possible que je vois ça davantage du point de vue développeur et moins du point de vue du dirigeant d'une équipe, puisque je travaille dans une EURL.

Le simple fait que ce type d'optimisation existe me hérise le poil.
Autant dire aux développeurs : allez-y codez comme des porcs, le compilo recollera les morceaux.
Il y aura toujours un paquet de fautes qu'il ne saura pas rattraper...

D'accord sur le fait que le compilateur ne fait pas tout (* quoique).

En revanche, pas d'accord sur le fait qu'écrire :

Code :

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

Point p = new Point(...);

dans une méthode très souvent appelée, comme mousemove, soit "coder comme un porc", pour peu qu'on sache que le compilateur va "corriger" le problème.
Je prends plus ça comme une particularité du langage en fait : si tu écris telle ligne de code, ça donnera tel résultat une fois compilé.
A partir du moment où on sait ce qu'on fait (et j'insiste sur le verbe savoir), peut-on vraiment dire qu'on code comme un porc ?

Dans le cas précédent, si le développeur sait que face à Point p = new Point(...); dans une méthode appelée très fréquemment, le compilateur va se charger d'optimiser p afin qu'il ait toujours la même adresse, pourquoi ce développeur s'embêterait à utiliser une autre méthode plus compliquée à mettre en oeuvre ?

Enfin je dis ça... Moi je trouve ça très expressif "Point p = new Point(...);". Sûrement beaucoup plus qu'une autre manière où le développeur ferait explicitement ce que fait le compilateur implicitement.

Ceci dit, y'a quand même des fois je regrette un peu la "simplicité" du C/C++ non managé.
Parce qu'en définitive (je bosse avec .NET moi, pas avec Java), .NET requiert quand même, je trouve, de faire un peu plus attention à ce qu'on fait qu'en non managé.
Enfin... Plus exactement, on fait attention à des choses différentes entre un environnement managé et un environnement non managé, résultat le passage de l'un à l'autre peut être un peu déroutant parfois.

Et la déroute saypacool paske ça fait perdre du temps :p.
Je pense que c'est ce que tu voulais dire, deneb, non ? Concernant ce dernier point : la déroute.

edit:
voilà que j'oublie ma petite étoile. Donc...
(*) : Concernant le fait qu'un compilateur fasse ou ne fasse pas tout. Il y a quelques temps j'avais tenté de mettre en place un programme qui avait pour vocation de programmer tout seul.
En fait, le principe était assez simple, je lui imposais un ensemble de contraintes, et il s'efforçait de me trouver une solution qui ne violait aucune de ces contraintes (via un algorithme génétique).
A noter que la bêbête programmait en..... lambda-calcul pur. Le truc super utile en entreprise quoi :p
N'empêche ça marchait ce programme. Ca marchait oui, mais fallait pas lui en demander trop non plus hein

[Luc Hermitte]

Depuis un moment, j'ai l'impression de lire des procès d'intention à l'encontre de tel ou tel autre langage. Ce n'est pas vraiment le lieu. Il y a d'autres fils pour cela.
Le sujet est les GCs. Pas Java contre le reste du monde.

Il y a plusieurs éléments qui me semblent complètement ignorés.

* Même en C++ il y a des GC.

* Le GC de C# est bien différent de celui de Java -- et il doit en exister encore bien d'autres variantes. Je ne suis pas sûr que les bidouilles avec l'un soient identiquement valables avec l'autre.

* Le débat peut aller beaucoup plus loin que GCs non déterministes d'un côté, et la gestion manuelle source d'erreurs de l'autre. P.ex, aujourd'hui, la "mode" en C++ est d'abandonner la gestion manuelle pour s'orienter vers une gestion déterministe (qui ne gère pas les cycles dans les versions les plus répandues).

EDIT2: Ce n'est pas parce que l'on utilise un GC que l'on ne peut pas en parallèle gérer finement la mémoire. C'est un problème de langage. Pas de GC!

Ce qui me gêne dans cette discussion qui tourne en rond, c'est que j'ai l'impression que d'un côté cela critique le GC de Java qui a ses faiblesses. Et de l'autre les autres langages mainstream (à demi-mot, le C et C++) qui n'ont pas de GC standard et qui ne me permettent de gérer la mémoire qu'à la main (ce qui est faux, en plus d'être déprécié dans le cas du C++).
Dans un cas comme dans l'autre, ces visions me paraissent extrêment réductrices. Il y a quantité de situations entre ces deux extrêmes cités tour à tour. (*)

Et non, on est pourtant loin d'avoir fait le tour de la question des GCs. Les courageux pourront trouver des discussions plus techniques, mais aussi plus philosophiques parfois, dans les archives de news://comp.lang.c++.moderated -- et non, ce n'est pas parce que c'est un forum de C++ qu'ils ont des oeillières, on y croise des gurus qui maitrisent théorie et/ou pratique, surtout quand ils se posent la question d'intégrer un GC au C++09 et que des membres du commité de standardisation participent aux discussions.


Concernant ma position:
- je ne ressens pas le besoin d'un GC qui a besoin d'être aidé avec des mises à null explicites dans des clauses finally -- surtout après avoir gouté au RAII (je me fais peut-être des fausses idées et cette bidouille n'est peut-être nécessaire plus qu'au milieu des cycles dans les dernières moutures des GCs des langages mainstream)
- je bosse en ce moment sur une appli où les perfs sont critiques, où des trames d'octets circulent à tout va. Et pourtant, je remplace régulièrement des gestions manuelles de mémoire par de la gestion implicite et déterministe.

Un GC qui me permettrait de faire la même chose avec une écriture simplifiée, je ne dirais pas forcément non. Si je me peux pas me dédouaner de la responsabilité de la gestion de la mémoire, alors j'ai une autre alternative dépourvue de surprises qui me va très bien pour l'instant.

Me concernant, un GC n'est pas fait pour gagner de la vitesse, il y a des pools, des allocations massives préventives, et diverses autres bidouilles pour cela.
C'est plus fait pour me permettre de me concentrer sur le métier et cesser de réfléchir à la mémoire -- ils ne peuvent rien faire concernant les autres ressources toutes aussi importantes.
Et malgré ce qui a été dit au sujet de l'irresponsabilité des développeurs, je pense que l'immense majorité de nos collègues attend avant tout d'être dédouanée de la gestion de la mémoire grâce aux GC. Aussi mauvais l'argument puisse-t-il être, c'est ce qui a été vendu, c'est ce qu'ils veulent. Pardon. C'est ce que l'on veut!

C'est un aspect social que l'on est forcés de reconnaitre, quelle que soit la qualité de l'implémentation du GC utilisé. C'est un peu le même problème entre C++ idiomatique et le C++ du terrain qui découle de migrations baclées/mal encadrées/qui-datent de populations de développeurs et d'enseignants passant du C au C++. Il y a des légendes et des mythes qui circulent. Ils s'auto-entretiennent et ont la vie particulièrement dure.
Il n'y a qu'à voir l'apriori que l'on lit ici : c'est soit GC, soit gestion manuelle.

EDIT:
(*) Cela me fait penser à ses méthodes de dialectives utilisées outre-atlantique où l'on entrelace des choses sans rapports dans un même discours, pour créer des associations d'idées. Sauf qu'ici, qu'au bout de 14 pages, on continue d'opposer les deux mêmes extrêmes scolaires, si je puis dire.
(Je m'en vais découper mon point de godwin)

[hedes]

Code :

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

1
2
Point p =  new Point(x,y) ;

Effectivement, cela n'est pas terrible. Cependant, au vu de mes tests, cela ne gaspille pas tant de mémoire que cela. ( Je crois me rappeler que les événements de souris ne sont pas aussi nombreux qu'on le pense quand on déplace la souris. )

Donc dans ce cas précis, ce n'est pas ultra grave.

Utilisation de variables pre-allouée : si on utilise une variable prè-allouée, il faut faire très attention si cette variable est par la suite partagée entre plusieurs threads : d'autres bugs, beacoup plus graves, peuvent survenir on perd en évolutivité etc.

Enfin, si un codeur écrit cela, il peut aussi écrire dans le même handler :

Code :

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

1
2
HugeObject ho = new HugeObject();

... et là c'est codé comme un "porc" !

[deneb]

Enfin, si un codeur écrit cela, il peut aussi écrire dans le même handler :

Code :

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

1
2
HugeObject ho = new HugeObject();

... et là c'est codé comme un "porc" !

A partir du moment où on dit au développeur que les new SmallObject() dans une méthode (ou une boucle) c'est pas un problème parce que le compilo veille, il n'éprouve plus moindre émotion à faire new UltraHeavyObject().

Il reste préférable de connaitre qq bons principes d'utilisation de la mémoire et de les respecter "par habitude" que de compter sur les corrections à postériori du compilateur. Ne serait-ce que pour s'éviter des déconvenues en changeant de language de même d'implémentation.

Et pour répondre au post de Luc, le sujet initial était "Pour ou contre le GC de Java". Cest un modérateur qui a créé ce sujet avec ce titre qui élargi un peu le débat. C'est d'ailleurs pas plus mal, mais cela explique pourquoi on parle essentiellement de GC java ici.
De GC en C++ je n'en ai connu qu'un seul, fait maison par la boite dans laquelle je bossais. Au début j'ai trouvé ça curieux, voir sympa mais je me suis souvent demandé à quoi ça pouvait bien servir au fond.
En fait il servait surtout à encapsuler les allocations pour les réaliser de manière spécifique sur chaque plateforme (Win,MaxOS, Linux), car le même code compilait sur les 3 plateformes.

[FremyCompany]

C'est quoi le rapport avec le manager ? Tu crois que faute de comprendre le GC il va dire "ouaip ben retour à la gestion manuelle de la mémoire!" ???

En effet, je rappelle que le sujet de thread, et donc la source des réponses de bien des personnes, est "Pour ou contre le GC ?".

Pour l'instant, deneb, j'ai la furieuse impression que tu oscilles entre des passages clairement anti GC, qui se font démonter, et des passages où tu pointes du doigt des améliorations, où les gens approuvent, en bouclant et et relançant sans fin le débât. Quelque chose de tout sauf cohérent et très usant à lire.

Moralité, sommes nous d'accord sur :
1 - Oui, la GC est une réelle avancée dans les applications sans gestion à l'octet de la mémoire/temps réel dur.
2 - Oui la GC est perfectible, toutes les contributions (constructives) sont les bienvenues ! Oui ou non ?

La première partie aura clot le présent débât

Je suis d'accord pour dire que mis à part deneb, personne n'est reellement contre le GC et je dirais même qu'il joue cavalier seul vs le reste... Le débat me semble tourner en rond et personne n'apprend rien...

EDIT2: Ce n'est pas parce que l'on utilise un GC que l'on ne peut pas en parallèle gérer finement la mémoire. C'est un problème de langage. Pas de GC

C'est bien la preuve d'une incompétence majeure des developpeurs critiquant le GC (voir un autre de mes post: )

Pour moi GC, y pas mieux pour gagner du temps, autant pour celui qui sait bien programmer que pour celui qui programme déjà depuis longtemps.

Et la methode manuelle, pas mieux quand on ne sait pas programmer ! La vous aller m'arrêter, c'est le contraire ! Ben non... Reprenons mon exemple de variable déclarée au début d'une fonction très longue et inutilisé très vite après : qu'est-ce qui vous a empeché de faire une fonction ? (Sub, function, void, ou tout ce que vous voulez, selon votre language) Ben oui, la sous-fonction, même utilisée une fois, permet de relacher l'instance de votre variable une fois la sous-fonction terminée et donc au final d'augmenter la puissance de votre application !

Deplus ici, l'utilisation est recommendable, vu que votre fonction de départ était longue... alors pourquoi ne pas la diviser en plusieurs petites sous fonction, ayant chacune une fonction déterminée, et surtout, un nom permettant d'y voir clair en lisant le code de la nouvelle "grande" fonction épurée !

Le problème de la variable inutilisée est donc un vis de programmation...

Je trouve aussi que le débat est un peu Java VS C++ car on prend chaque fois comme référence le java (GC) et le C++(!GC)... et ce déjà dès le début...

Alors si vous tenez à discuter des avantages inconvénient du GC sous Java, aller dans le forum Java Sinon, il vous faut prendre en compte les évolutions que celui-ci a adopté dans les autres langages et que Java, qui sait, adoptera peut-être un jour lui aussi !

Et je pense que le débat est clos (m^me si je sais bien que deneb ne pourra s'empecher de répondre à ce message )

[mat.M]

Je trouve que Java est un très bon language, que la JVM est une idée lumineuse, mais que le GC est une erreur (c'est mon point de vue).
Alors je pose la question pour voir si je suis le seul fou à préférer faire ce boulot à la main où s'il y en a d'autres comme moi .

eh non ( attention je ne prend pas parti pour telle ou telle technique ) ,
on ne peut pas dissocier le GC de Java pour la bonne et unique raison que Java ce sont des programmes distribués via des réseaux ( tout comme , .NET , qui porte bien son nom d'ailleurs);
qui dit programmes tournant sur des réseaux ( servlets, applets..) un controle de la stabilité du programme et de la mémoire se doit d'être rigoureux , en théorie bien sur...

Java est multiplateforme donc lorsqu'une appli Java tourne sur un OS particulier c'est normal de laisser "propre" et "sur" l'OS en quittant ..
Il faut se rappeler pourquoi Sun Microsystems a mis au point et lancé ce langage : il se veut multiplateforme ,"client-serveur" offrant une transparence pour le programmeur qui ne se préoccupe pas de savoir si cela tourne en local ou à distance..

On ne peut pas concevoir une telle technologie sans un controle des erreurs minimum sans GC.
D'ailleurs comme le dit très bien Luc même avec C++ il y a un "runtime" minimal pour le controle des erreurs..

[deneb]

Je suis d'accord pour dire que mis à part deneb, personne n'est reellement contre le GC et je dirais même qu'il joue cavalier seul vs le reste... Le débat me semble tourner en rond et personne n'apprend rien...

C'est bon vous m'avez convaincu, j'adore maintenant le GC, on peut fermer le sujet.

[FremyCompany]

C'est bon vous m'avez convaincu, j'adore maintenant le GC, on peut fermer le sujet.

Lol, n'en dit rien de trop, je respecte ton avis. Si tu n'aimes pas le GC, libre est ton droit. Le débat a d'ailleurs été intéressant dans son début. ;)

[epsilon68]

Je tenais juste a faire part de mon experience sur le garbage....
en fait au travail, on utilise plus que exclusivement le Java ou le .NET,
et maintenant le temps ou on gerait la memoire semble etre a sa fin.
Nos applications sont typiquement des applis de gestion avec database, et aussi du JSP/ASP. d'ailleurs la proportion des clients devient ridicule par rapport aux applis web....

et franchement au travail, il y a vraiment beaucoup de pression, entre le client, la date de livraison et le budget, la gestion memoire et la recherche du mauvais delete serait de tres mauvaise augure.

Maintenant je fais aussi du C++ avec Qt a la maison, plus orienté geometrie 3d. et j'aime bien. J'avais été tres decu de Java et du garbage dans ces conditions. J'avais d'ailleurs fait le meme programme dans les deux languages, et c'est impressionnant la memoire qui peut etre utilisé, et ca prend vite de grande proportions quand c'est un model avec beaucoup de faces.

Aussi, je ne vis pas de ca et cela represente une part de marché assez insignifante... je pense.

En fait pour conclure, J'aimerais assez bien avoir le choix dans le meme language de pouvoir utiliser le garbage ou non, et le C++ me semble etre en bonne position. Mais sans modifier le language comme .NET fait.
un truc du genre new(gc). Mais les smart pointer resolvent pas mal de problemes, et (argh beaucoup vont me tomber dessus) Qt et le CopyOnWrite simplifie beaucoup le codage sans copier a tout va.

Je tenais aussi a dire que ce debat etait interessant a lire bien qu'un peu long.

a+

[GnuVince]

J'ai pas lu le débat au complet, mais je suis pour les GC pour une raison que j'ai lu dans la première page: ça permet de se concentrer sur le vrai problème à résoudre.

Programmer est difficile. Les tâches que nos programmes doivent accomplir pour nos clients sont très (même trop) souvent complexes et je suis d'avis qu'un programmeur n'a pas besoin de penser à des choses comme la gestion de la mémoire (ou des trucs encore de plus bas niveau) quand la tâche à accomplir prend suffisament de cycles de son cerveau. Les GC modernes (pas les ref counters) sont souvent (notez, pas tout le temps) aussi performants que si la gestion de la mémoire étaient faite par un humain.

Aussi, je me demande si des fonctionalités avancées comme des continuations, des closures, les process comme dans Erlang sont faisables de façon simple à utiliser dans un langage où la gestion de la mémoire est manuelle.

[Luc Hermitte]

J'ai pas lu le débat au complet,

C'est mal.

mais je suis pour les GC pour une raison que j'ai lu dans la première page: ça permet de se concentrer sur le vrai problème à résoudre.

Sauf que c'est une illusion. Sinon il n'y aurait pas ces problèmes de fuites de mémoires capables de plomber des terminaux connectés des jours durant.
(non, non je n'ai pas dit le contraire il y a une 10aine de messages de cela, juste que c'est ce que l'on nous a vendu et que l'on veut, pas que c'est suffisant pour se dédouaner)

Ce n'est pas parce que l'on utilise des GC qu'il faut arréter de réfléchir.

[epsilon68]

on n'a pas dit arreter de reflechir mais reflechir sur d'autres problemes...

[GnuVince]

C'est mal.

Sauf que c'est une illusion. Sinon il n'y aurait pas ces problèmes de fuites de mémoires capables de plomber des terminaux connectés des jours durant.
(non, non je n'ai pas dit le contraire il y a une 10aine de messages de cela, juste que c'est ce que l'on nous a vendu et que l'on veut, pas que c'est suffisant pour se dédouaner)

Ce n'est pas parce que l'on utilise des GC qu'il faut arréter de réfléchir.

J'ai pas dit ça non plus. Par contre, ne blâme pas les mauvaises implémentations de GC dans Java ou dans JavaScript comme une raison pour dire que le GC est mauvais, sinon on pourrait dire que la gestion de la mémoire manuelle c'est problématique parce que Ti-Joe Connaissant sait pas comment bien la gérer dans C. Je suis pas au courant des dernières percées dans les GC, mais l'auteur de langage Factor, Slava Pestov (auteur de jEdit) mentionne que le garbage collector dans son langage est très supérieur à celui dans Java, car il utilise des techniques plus modernes. J'y connais rien à l'implémentation de langages, mais le type est super brillant et connais bien Java et parle très souvent contre.

Je suis bien convaincu qu'à force de recherche et de travail, les GC vont devenir énormément plus fiable et performant qu'ils le sont aujourd'hui et que l'importance de la gestion de la mémoire manuelle va encore diminuer.

[alex00]

Bonjour,

debat interessant, meme si je n'ai pas pu tout lire !

Utiliser un GC, tout comme des smart-pointers, permet de s'affranchir d'une responsabilite, d'un travail supplementaire... pour se consacrer sur les fonctions a implementer.
d'ou un gain de temps.

Ce qui implique par contre tres souvent une perte de qualite du design: mauvaises attributions des responsabilites (cf. pattern GRASP), dependances circulaires en vrac, ... et au final un code qui marche, assez stable (facilite la maintenance), mais difficile de s'y retrouver (freine la maintenance).

Personnellement, je prefere aussi avoir a gerer la duree de vie des objets (enfin, avoir un design qui tient la route)

Alex
(mes techno: UP, UML, C++ & Java)

[Macss]

Désolé je n'ai pas tout lu le débat par manque de temps, peut-être que j'y reviendrai en fin de semaine parce que ca me semble très interressant. Pour l'instant je vais seulement aporter mon opinion. Personnelement je n'aime pas l'idée d'un garbage collector. Oui, ca rend la programmation plus facile mais un garbage collector ne fera jamais autant la job qu'un programmeur consciencieux peut faire. Sur des appareil avec des ressource minime comme les téléphones cellulaires, un GC à mon avis est une vrai joke ! La gérance de la mémoire ne sera jamais aussi précise que en la gérant par nous même.

[gorgonite]

Sur des appareil avec des ressource minime comme les téléphones cellulaires, un GC à mon avis est une vrai joke ! La gérance de la mémoire ne sera jamais aussi précise que en la gérant par nous même.

le téléphone mobile est le mauvais exemple par excellence... presque tous gèrent désormais la J2ME (CLDC ou autre), et certains ont même désormais des KVM avec JIT (esmertec & cie)

il faut savoir que les quantités de mémoire embarquée dans ses machines est devenu énorme en l'espace de quelques années... 2 Go sur une SIM désormais !!!


en revanche, je suis d'accord que sur des systèmes embarqués plus restreints, le Java n'est pas forcemment utilisable : en gros, il faut 300Ko pour la CLDC avec son API, et 1Mo de heapsize pour faire tourner des benchmarks du type JGrande... donc pas mal de programmes "standards"
en dessous, il faut chercher une autre solution


pour le domaine temps-réel, je dirais qu'à la fois le JIT et le GC sont des mauvaises idées, même s'il faut nuancer ces propos avec des techniques comme le DAC (compilation à la volée très peu couteuse) ou les API Reflex (pour les systèmes hyper-réactifs, avec des gestionnaires de signaux capables de prendre la main sur tout le reste, y compris le GC )

[Macss]

le téléphone mobile est le mauvais exemple par excellence... presque tous gèrent désormais la J2ME (CLDC ou autre), et certains ont même désormais des KVM avec JIT (esmertec & cie)

Je ne suis pas tout à fait d'accord, beaucoup de téléphone n'ont pas encore asser de ressource. Je vis au canada et nos téléphones sont très en retard par rapport aux autres pays, nous n'avons même pas encore le 3G peut-être une petite partie de Toronto mais encore la je ne suis pas sur. Le téléphone que je viens d'acheter supposément dernier cri est le LG245 qui est très dépassé par rapport à ce que je vois sur Internet. La seul manière d'avoir une téléphone potable ici c'est de le commander par Internet et il n'y qu'une seul compagnie qui gère les cartes SIM et c'est Rogers.