Sauf le garbage collector, quoi d'autre fait de Java un langage de programmation non temps réel

À l'exception du garbage collector, quelles sont les autres fonctionnalités de Java qui le rendent inapproprié pour la programmation en temps réel? Sur le net, chaque fois que Java vs C ++ est discuté en ce qui concerne la programmation en temps réel, c'est toujours le garbage collector qui est mentionné. Y a-t-il autre chose?

— Kaushik
source

Même la collecte des ordures n'est pas un problème - il existe plusieurs collecteurs d'ordures en temps réel. Ceux qui mentionnent le gc comme un bouchon de show en temps réel sont tout simplement incompétents.

— SK-logic

@ SK-logic s / incompetent / uninformed / g

— Scott Whitlock

@ScottWhitlock, d'accord, la plupart d'entre eux le sont. Mais certains (les plus vocaux) continuent d'insister même après avoir été correctement informés. Je ne connais aucune explication rationnelle à ce phénomène anthropologique.

— SK-logic

Réponses:

Il y a deux éléments supplémentaires dont je me souviens spontanément:

Compilation JIT
Mise en œuvre du filetage

En termes de temps réel, la prévisibilité des performances est probablement le facteur le plus important; C'est pourquoi un cycle GC imprévisible rend Java impropre au temps réel.

JIT offre des performances améliorées, mais intervient à un moment donné après l'exécution du programme, en prenant certaines ressources et en modifiant les vitesses d'exécution du système. Cela peut également se reproduire ultérieurement, si la machine virtuelle estime qu'elle peut faire un "meilleur" travail à ce moment-là.

En ce qui concerne le filetage: je ne me souviens pas très bien à ce stade si cela fait partie de la conception du langage, ou simplement une implémentation très courante, mais Java ne fournit généralement aucun outil pour contrôler précisément l'exécution des threads; Par exemple, alors qu'il existe 10 "priorités" spécifiées pour les threads, il n'y a aucune exigence que la machine virtuelle considère réellement ces priorités. Les opérateurs d'arrêt et de commutation de threads ne sont pas non plus définis, ni adhérés de manière rigide par le système.

Il existe plusieurs implémentations de JSR 1: Spécification en temps réel pour Java - une spécification qui a été approuvée en 1998. Cette spécification résout autant que possible les problèmes qui rendent Java standard impropre au temps réel.

Il y a peut-être 5 ans, Sun (maintenant Oracle) avait une VM RTSJ (qui n'a jamais eu de nom, AFAIK); IBM avait WebSphere Real Time; Et JamaicaVM était une solution gratuite (?), Indépendante de la plateforme. Googler ceux d'aujourd'hui n'apporte pas grand-chose.

— aviv
source

Un autre problème, bien que faible en comparaison, est qu'une classe n'est chargée que lorsqu'elle va être utilisée.

— T-Bull

Il n'y a rien dans la spécification Java qui appliquera JIT au lieu d'AOT ou d'une interprétation pure. Les fils verts purs sont totalement prévisibles, ils ne peuvent donc pas non plus être un obstacle en temps réel.

— SK-logic

la sphère Web en temps réel semble au moins toujours être prise en charge (affirme la prise en charge de Java 7.0 et vous pouvez accéder à une page pour l'acheter)

— jk.

@ SK-logic - droit, bon point!

— aviv

Le système d'exploitation

Tant que Java s'exécute sur Unix ou Windows ou tout autre système d'exploitation «normal», le temps réel n'est pas garanti.

Un système d'exploitation en temps réel est obligatoire pour exécuter des applications en temps réel.

— mouviciel
source

@Giorgio: pour de solides garanties en temps réel? Oui.

— Joachim Sauer

De plus, il existe des systèmes d'exploitation disponibles qui sont conçus pour le temps réel dès le départ, par exemple FreeRTOS.

— medivh

Bien que ce soit un point très important pour le temps réel dur en général, il ne semble pas du tout être spécifique à Java. Suis-je en train de manquer quelque chose?

@delnan, le fait est que même si vous utilisez une implémentation en temps réel (imaginaire?) d'une machine virtuelle Java, cela n'aide pas beaucoup si le système d'exploitation ne peut pas vous donner de garanties en temps réel.

— schlingel

@delnan - La question a de fausses prémisses, suggérant que C ++ est un langage de programmation en temps réel.

— mouviciel

Techniquement, il est possible d'avoir du java en temps réel (comme le suggèrent les commentaires de SK-logic). cependant, il n'est pas courant pour un certain nombre de raisons non techniques:

Anciennes normes

Ayant du mal à trouver une référence pour cela, mais je suis certain que j'ai vu des normes de sécurité, ou des conseils de conformité aux normes de sécurité, mettre une interdiction générale sur Java. À tort ou à raison, si vous devez vous conformer à quelque chose qui dit que Java est verboten, alors Java est Verboten.

Vieux ingénieurs de sécurité

Même si les normes dont vous avez besoin pour ne pas interdire Java, travailler avec des auditeurs de sécurité / qualité sans expérience de Java signifie que vous ne suivez pas le chemin de la moindre résistance. Tout ce qui sort de l'ordinaire pour l'auditeur attirera probablement beaucoup de questions, ce qui signifie à son tour beaucoup de travail pour justifier vos choix.

La communauté

c'est-à-dire qu'il y a beaucoup de dépendance de chemin, la plupart des experts actuels en temps réel connaîtront le C ++, le C ou l'ADA à l'envers donc c'est un choix naturel pour faire de nouveaux travaux.

(Remarque: j'ai un peu confondu en temps réel et la sécurité dans ce qui précède, ce qui est en quelque sorte un autre problème, car même les normes de sécurité confondent souvent les deux)

— jk.
source