Bonjour,
Question existentielle sur Java : Pourquoi la JVM est dépendante du type de processeur?
Version imprimable
Bonjour,
Question existentielle sur Java : Pourquoi la JVM est dépendante du type de processeur?
........ Parce que les processeurs sont incompatibles.
Grosso-modo, même raison que celle pour laquelle un programme pour x86-64 ne marche pas sur x86 standard.
Parce que la JVM interprete le programme Java et l'execute sur le processeur. Elle doit donc bien savoir comment communiquer avec celui-ci. Et comme ils sont incompatibles entre eux... D'ailleurs, on pourrait se poser la meme question pour l'OS. Et la reponse sera la meme...
D'accord, merci pour vos réponses. Je me doutais un peu de la chose, mais en fait je pose cette question car je n'ai pas très bien compris comment le bytecode Java est exécuté.
Sans prendre en compte le JIT compiler, le bytecode est interprété (je ne me trompe pas?), et à ce moment là je me pose la question : interprété en quoi?! 2 possibilités :
1) en appel à des fonctions système, alors à ce moment là je ne comprend pas la dépendance au CPU vu que les fonctions systèmes sont indépendantes du CPU (je parle de leur appel, pas de leur implémentation)
2) interprété en instruction cpu? Donc à ce moment là je comprend la dépendance CPU, mais je ne pense pas que cette solution soit juste car on n'utiliserait pas le mot "interprété". De plus c'est déjà ce que fait le JIT compiler (son seul avantage est qu'il le fait juste avant que ça soit nécessaire en plus des optimisations)
Dans le cas des exécutables (le "java" dans le dossier "bin" et autres nécessaire à l'exécution) je comprend la dépendance au système et au cpu, pas de problème. Encore que, pourquoi est ce qu'on ne télécharge pas les sources pour ensuite les compiler nous-mêmes, c'est moins "grand-public" ok, mais ça pourrait être disponible en plus.
De même pour les API Java fournie, je peux imaginer la dépendance cpu. Il me semble avoir vu du code assembleur dedans.
Voilà mon problème, qu'est ce qui est dépendant du système, qu'est ce qui est dépendant du CPU et qu'est ce qui est indépendant?
Est ce que quelqu'un a un bon document sur le fonctionnement de la jvm, ou bien peut répondre à toutes mes interrogations ! ;)
Salut,
Salut,
Ben... Le "java" c'est la JVM !Citation:
Envoyé par Bertrand88
La JVM doit pouvoir s'exécuter sur le système, donc il s'agit d'une application native prévu pour un système et une architecture précise (comme toutes les applications natives).
Son rôle consister à interpréter/compiler le bytecode afin de l'exécuter sur le système et le matériel hôte.
a++
C'est interprété par la JVM. En gros, le byte code contient "afficher un carré à l'ecran" et la JVM l'affiche (donc fait les appels systeme qui vont bien pour qu'il apparaisse).Citation:
Envoyé par Bertrand88
Les fonctions systeme sont différentes meme sur un meme processeur sur 2 OS différents. Alors sur 2 processeurs... Pour t'en convaincre, regarde du coté de sources disponibles pour Linux ARM et x86. Tu vas voir que pas mal d'applications tournent sur x86 et pas ARM...Citation:
Envoyé par Bertrand88
Ca se fait... Mais pour les raisons evoquées plus haut, les sources seront différentes sur 2 architectures/OS différents.Citation:
Envoyé par Bertrand88
Du code assembleur dans une API Java ??? J'aimerais voir ca.Citation:
Envoyé par Bertrand88
L'OS est dépendant du systeme (CPU) et la JVM est dependante de l'OS (et donc du systeme). En revanche le bytecode java est indépendant du systeme.Citation:
Envoyé par Bertrand88
Merci beaucoup pour toutes vos réponses ! Ca a répondu à toutes les questions que je me posais !
Pour le code assembleur dans l'API Java j'ai du rêver... :roll:
En fait j'ai une dernière question ! :calim2:
Je regarde les jvm open-source comme OpenJDK et Harmony, et je ne comprend pas pourquoi ils ne peuvent pas être "buildés" sur n'importe quelle plateforme. (par exemple : http://harmony.apache.org/supported_platforms.html)
Vu qu'ils sont programmés en C++ et Java, du moment qu'on dispose du compilateur adéquat pour le C++, ça devrait marcher non?! :roll:
Oui... et non !Citation:
Envoyé par Bertrand88
La portabilité d'une application native n'est pas si simple.
Déjà comme tu l'as dit il faut que le compilateur adéquat soit disponible sur la plateforme cible.
Mais il faut également que les librairies utilisées le soient également. Sans compter que certaines parties du code pourraient très bien être spécifique à un système ou une architecture, et dans ce cas là il faudra coder cette partie spécifique pour le nouveau système cible...
Bref il ne suffit pas forcément de recompiler...
a++
ok merci ! J'avais regardé les pages wikipedia de ces 2 projets et c'etait seulement marqué qu'ils etaient implémenté en Java et C++, pas assembleur. Et je n'y avais pas pensé.
Pour information, après ta réponse je suis tombé sur le projet IcedTea, intégré au projet OpenJDK qui à ce que j'ai compris a pour but entre autre de se passer de l'assembleur et donc de rendre la jvm totalement portable :
http://en.wikipedia.org/wiki/IcedTea#Zero_and_Shark
Le problème ne vient pas forcément que de l'assembleur. Il peut également y avoir des librairies natives spécifiques qui n’existeraient pas en l'état sur les autres supports...
La portabilité d'une application native n'est pas si simple !
a++
exemple typique:
Runtime.getRuntime.exec().
Sous unix/bsd, on doit passer par un fork, un synchronisation des process et au final un exec dans le process enfant.
Sous windows, fork n'existe pas, il existe d'autres méthodes.
L'affichage de awt. Sous linux, on utilise Xorg, sous windows, soit la winapi, soit directx, soit d'autres trucs suivant la version. Sous mac os x, il faut faire des appels à cocoa.
Merci pour vos réponses ! :ccool: