Ceux qui commencent tout juste à se familiariser avec Java sont souvent confus quant aux concepts de code machine et de code octet . Quels sont-ils? Quelles sont les différences? Dans une courte note, nous essaierons de décrire leurs caractéristiques aussi simplement et clairement que possible afin de clore ce problème une fois pour toutes.
Langage machine
Le processeur est, par essence, une calculatrice très complexe et avancée. Il possède de nombreux emplacements mémoire (appelés registres) sur et entre lesquels diverses opérations mathématiques et sur les octets sont effectuées. Le code machine est précisément une description de la séquence d’opérations et de l’ensemble des données impliquées. En fait, c’est la seule langue que comprend le processeur de votre ordinateur.
Incompatibilité congénitale
Dans le même temps, tous les processeurs ne « parlent » pas le même langage. Il existe des différences non seulement entre les architectures CISC et RISC , mais également au sein de ces « camps ».
CISC (Complex Instruction Set Computing) est un concept de conception de processeur caractérisé par l'ensemble de propriétés suivant :
de nombreuses commandes, de longueur différente ;
de nombreux modes d'adressage ;
codage d’instructions complexes.
RISC (Reduced Instruction Set Computing) - un processeur avec un jeu d'instructions réduit. Les commandes sont du même format, courtes, avec un codage simple.
Les nouvelles générations de processeurs introduisent des jeux d’instructions supplémentaires qui sont tout simplement inconnus des modèles des anciennes générations. Pour cette raison, les programmes compilés pour une architecture (ou une génération de processeurs) ne peuvent pas fonctionner sur un autre matériel. Tout cela nous oblige à recompiler les programmes pour garantir qu'ils fonctionnent sur d'autres ordinateurs. Cependant, vous devez recompiler non seulement à cause des processeurs, mais également à cause des différences dans l'interaction des programmes et du système d'exploitation. C'est à cause d'eux qu'il est impossible d'exécuter un programme « Windows » sous Linux, et un programme « Linux » sous Windows.
Bytecode
Le bytecode est à bien des égards similaire au code machine, sauf qu'il utilise un ensemble d'instructions provenant non pas d'un processeur réel, mais d'un processeur virtuel. De plus, il peut inclure des sections axées sur l'utilisation d' un compilateur JIT , qui optimise l'exécution des commandes pour le processeur réel sur lequel le programme s'exécute.
La compilation JIT (compilation juste à temps, compilation à la volée) ou compilation dynamique (traduction dynamique) est une technologie permettant d'augmenter les performances des systèmes logiciels qui utilisent le bytecode en compilant le bytecode en code machine ou dans un autre format directement pendant le programme est en cours d'exécution. « Officiellement » en Java jusqu'à la version 9, il n'y avait qu'un compilateur JIT. Dans Java 9, un autre compilateur est apparu, et il compile à l'avance (AoT). Cette fonctionnalité permet aux classes Java d'être compilées en code natif avant de s'exécuter sur une machine virtuelle. Cette fonctionnalité est conçue pour améliorer les temps de démarrage des petites et grandes applications, avec un impact limité sur les performances maximales.
Pour les processeurs CISC , certaines instructions peuvent être combinées en structures plus complexes supportées par le processeur, et pour RISC , au contraire, elles peuvent être décomposées en séquences d'instructions plus simples.
Également un système d'exploitation virtuel
Cependant, le byte code ne contient pas seulement des instructions du processeur. Il contient également une logique d'interaction avec un système d'exploitation virtuel, ce qui rend le comportement de l'application indépendant du système d'exploitation utilisé sur l'ordinateur. Ceci est clairement visible dans la JVM , où le travail avec les appels système et l'interface graphique sont souvent indépendants du système d'exploitation sur lequel le programme s'exécute. Dans l'ensemble, la JVM émule le lancement d'un processus de programme, contrairement à des solutions comme Virtual Box , qui créent uniquement un système/matériel virtuel.
Est-ce que JVM est le seul à ressembler à ça ?
Définitivement pas. La même CLI DotNet est également une machine virtuelle, qui est le plus souvent utilisée sur les ordinateurs exécutant Windows avec des processeurs compatibles x86. Cependant, il existe son implémentation pour d'autres systèmes : les applications doivent fonctionner sur Windows RT fonctionnant sur des processeurs compatibles ARM (RISC) , ou vous pouvez les exécuter sur Linux/OSX dans l' environnement Mono , qui est un tiers (et donc pas entièrement compatible) implémentation de DotNet pour ces plateformes. Cette plateforme, comme la JVM , fonctionne donc sur différents processeurs et différents systèmes d'exploitation. Il existe de nombreuses autres solutions similaires (anciennes et nouvelles) : LLVM , Flash SWF et autres. Certains langages de programmation possèdent leurs propres machines virtuelles. Par exemple, CPython compile les sources PY dans des fichiers PYC - du code d'octet compilé prêt à être exécuté dans PVM . Ou il existe un exemple beaucoup plus ancien : Lisp peut être compilé en fichiers FASL (Fast Load). En fait, ils contiennent un arbre AST construit par le générateur à partir du code source. Ces fichiers peuvent être lus et exécutés par l' interpréteur Lisp sur diverses plates-formes, ou utilisés pour générer du code machine pour l'architecture matérielle actuellement utilisée.
GO TO FULL VERSION