Pourquoi la JVM est-elle basée sur la pile et Dalvik VM basée sur le registre?
Je suis curieux, pourquoi Sun a-t-il décidé de faire la pile JVM et Google a-t-il décidé de faire la base de registre DalvikVM?
Je suppose que la JVM ne peut pas vraiment supposer qu'un certain nombre de registres sont disponibles sur la plate-forme cible, car elle est censée être indépendante de la plate-forme. Pour cela, il reporte simplement l'allocation de registre, etc., au compilateur JIT. (Corrige moi si je me trompe.)
Donc, les gars de Android ont pensé: "hé, c'est inefficace, allons tout de suite pour un registre basé sur vm ..."? Mais attendez, il existe plusieurs appareils Android différents, quel nombre de registres le Dalvik a-t-il ciblé? Les opcodes Dalvik sont-ils codés en dur pour un certain nombre de registres?
Tous les appareils Android actuels sur le marché ont-ils à peu près le même nombre de registres? Ou, y a-t-il une réallocation de registre effectuée pendant le chargement dex? Comment tout cela s'intègre-t-il?
Il y a quelques attributs d'un VM basé sur la pile qui correspondent bien aux objectifs de conception de Java:
Une conception basée sur la pile fait très peu d'hypothèses sur le matériel cible (registres, fonctionnalités du processeur), il est donc facile d'implémenter un VM sur une grande variété de matériel).
Comme les opérandes des instructions sont largement implicites, le code objet aura tendance à être plus petit. Ceci est important si vous allez télécharger le code sur une liaison réseau lente.
Aller avec un schéma basé sur un registre signifie probablement que le générateur de code de Dalvik n'a pas à travailler aussi dur pour produire du code performant. L'exécution sur une architecture extrêmement riche ou pauvre en registres handicaperait probablement Dalvik, mais ce n'est pas la cible habituelle - ARM est une architecture très intermédiaire).
J'avais également oublié que la version initiale de Dalvik ne comportait pas du tout de JIT. Si vous allez interpréter les instructions directement, un schéma basé sur un registre est probablement un gagnant pour les performances d'interprétation.
Je ne trouve pas de référence, mais je pense que Sun a opté pour l'approche du bytecode basé sur la pile, car elle facilite l'exécution de la JVM sur une architecture avec peu de registres (par exemple IA32).
Dans Dalvik VM Internals de Google I/O 2008, le créateur de Dalvik Dan Bornstein donne les arguments suivants pour choisir un registre basé sur = VM sur la diapositive 35 des diapositives de présentation :
Enregistrer la machine
Pourquoi?
- éviter l'envoi d'instructions
- éviter tout accès inutile à la mémoire
- consommer efficacement le flux d'instructions (densité sémantique plus élevée par instruction)
et sur la diapositive 36:
Enregistrer la machine
Les stats
- 30% moins d'instructions
- 35% d'unités de code en moins
- 35% d'octets en plus dans le flux d'instructions
- mais on arrive à en consommer deux à la fois
Selon Bornstein, il s'agit "d'une attente générale que vous pourriez trouver lorsque vous convertissez un ensemble de fichiers de classe en fichiers dex".
La partie pertinente de la la vidéo de présentation commence à 25h .
Il existe également un article perspicace intitulé "Virtual Machine Showdown: Stack Versus Registers" par Shi et al. (2005) , qui explore les différences entre les machines virtuelles basées sur la pile et les registres.
Je ne sais pas pourquoi Sun a décidé de créer une pile JVM. Machine virtuelle Erlangs, BEAM est basé sur un registre pour des raisons de performances. Et Dalvik semble également être basé sur un registre pour des raisons de performances.
De Pro Android 2 :
Dalvik utilise des registres comme principalement des unités de stockage de données au lieu de la pile. Google espère ainsi obtenir 30% d'instructions en moins.
Et concernant la taille du code:
Le Dalvik VM prend les fichiers de classe Java Java générés et les combine en un ou plusieurs fichiers exécutables Dalvik (.dex). Il réutilise les informations en double de plusieurs fichiers de classe , ce qui réduit de moitié l'espace requis (non compressé) par rapport au fichier .jar traditionnel. Par exemple, le fichier .dex de l'application de navigateur Web en Android est d'environ 200 Ko, tandis que le .jar non compressé équivalent La version est d'environ 500 Ko. Le fichier .dex du réveil est d'environ 50 Ko, et environ deux fois cette taille dans sa version .jar.
Et si je me souviens bien Architecture informatique: une approche quantitative conclut également qu'une machine à registre fonctionne mieux qu'une machine basée sur la pile.