Discussion :

[wafiwafi]

Bon{jour,soir},
Quelqu'un a un résumé du fonctionnement ou plutôt l'échange établi entre le runtime Java et le système d'exploitation du point de vue mémoire?
Est ce que le runtime Java adresse en dur la mémoire que lui attribue le système d'exploitation après une demande (création du processus lors de l'exécution du programme, demande de mémoire en dynamique...)?
Le moteur d'exécution du runtime Java fait simplement la traduction du p-codes en code machine?
Merci à vous

[Melem]

Je vais essayer de te l'expliquer de la manière la plus simple du monde, c'est-à-dire sans faire intervenir la notion de plateforme Java (qui fait croire que les applications Java sont ... des applications !).

- Tu as une application Java : myapp.class (qui est peut-être dans une archive jar, d'ailleurs les programmeurs java disent qu'un .class n'est pas une application Java complète, mais on s'en fiche)
- Tu as un PC sur lequel est installé MS Windows.
- Tu veux lancer myapp.class sur ton PC.

Le problème c'est que Windows ne sait exécuter que des .exe, pas des .class ... La solution à ton problème : Demander à un .exe d'exécuter les instructions Java contenues dans myapp.class. Il faut donc évidemment que cet exe connaisse bien comment est organisé un fichier .class. Un tel exe est appelé un interpréteur Java. Un exemple d'interpréteur Java : le fichier java.exe du JRE de Sun.

Donc, pour bien comprendre la relation qu'il y a entre le système et Java, il faut se mettre du côté du système : le système ne voit que java.exe. C'est la véritable application que tu lances lorsque tu demande l'exécution de myapp.class. myapp.class est juste un fichier fourni en paramètre de java.exe, c'est comme n'importe quel fichier de données (il ne faut donc même pas la voir comme une application). Il dicte seulement ce que java.exe doit faire mais l'application que tu lances, c'est à chaque fois java.exe. En résumé : lancer myapp.class = lancer java.exe (avec en paramètre myapp.class).

java.exe peut lui-même faire appel à d'autres exe et/ou d'autres dlls, etc. mais ça ne change rien aux explications ci-dessus.

[wafiwafi]

Merci pour ces précisions clairs. J'ai bien compris. Néanmoins, ce que tu m'as précisé ressemble grandement au rôle du moteur d'exécution de JAVA (voir http://www.larcher.com/eric/guides/javactivex/III.htm).
Par contre ma question était également si le runtime adresse en dur la mémoire attribué à son processus.

[Melem]

Prends un exemple car je ne pense pas avoir compris ce que tu veux dire par adresser en dur la mémoire. Chaque processus, JVM ou non, dispose de son propre espace d'adressage. Il fait ce qu'il en veut. De toute façon il sera tué s'il fait quelque chose que l'OS n'aime pas. C'est tout ce que je peux dire avant que je comprenne bien ta pensée.

[wafiwafi]

adresser en dur la mémoire

Prenons l'exemple d'un compilateur qui réserve de la mémoire à l'avance pour les variables globales. Le fichier en langage machine, qui en l'occurrence fait appel aux différentes adresses de la mémoire, doit être compréhensible par le microprocesseur ; seulement , voila les choses ne se passent pas vraiment de cette manière dans la mesure où les adresses utilisées par le compilateurs/runtime sont certainement relogées pour une question de sécurité ou tout simplement d'une gestion propre à l'OS.
La question que je me pose, est ce que le runtime a à sa disposition les vrais adresses mémoire ( d'où le terme en dur) ou sont elles effectives.
Une autre question que je me pose : Dans le fichier produit par le compilateur, trouve -t- on des adresses mémoire ? où elles sont plutôt produites par le runtime pendant l'exécution.
Bien à toi

[Melem]

Prenons l'exemple d'un compilateur qui réserve de la mémoire à l'avance pour les variables globales. Le fichier en langage machine, qui en l'occurrence fait appel aux différentes adresses de la mémoire, doit être compréhensible par le microprocesseur ; seulement , voila les choses ne se passent pas vraiment de cette manière dans la mesure où les adresses utilisées par le compilateurs/runtime sont certainement relogées pour une question de sécurité ou tout simplement d'une gestion propre à l'OS.

Ce dont on peut déjà être sûr c'est que dans un .class il n'y aura jamais de "vraies adresses" codées en dur, sinon il ne serait pas "portable" (du simple que fait le nombre de bits utilisés pour représenter une adresse peut varier d'un système à un autre par exemple, et que la manière d'interpréter ces bits n'est pas universelle non plus ...). Les adresses "en dur" contenues dans la classes sont "abstraites". Soit par exemple une variable globale x référencée par l'adresse "J_x" dans le .class. Lors du démarrage de l'application, la JVM va réserver la mémoire qui sera effectivement utilisée par cette variable. Son adresse dans la mémoire virtuelle de la JVM sera par exemple "W_x" (qui a peu de chances d'avoir été codé en dur). Chaque fois tu demanderas un accès à J_x, la JVM va te positionner sur W_x. J'ai bien répondu ?

[wafiwafi]

Oh oui. C'est très clair! Merci beaucoup