Pourquoi la pile JVM et la VM Dalvik sont-elles basées sur les registres?

Je suis curieux de savoir pourquoi Sun a décidé de rendre la pile JVM basée sur la pile et Google a décidé de créer 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.)

Alors les gars d'Android ont pensé, "hé, c'est inefficace, allons tout de suite pour une VM basée sur un registre ..."? 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 de dex? Comment tout cela s'articule-t-il?

Il existe quelques attributs d'une machine virtuelle basée sur une pile qui correspondent bien aux objectifs de conception de Java:

1. 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 une machine virtuelle sur une grande variété de matériel.

2. Les opérandes des instructions étant largement implicites, le code objet aura tendance à être plus petit. Ceci est important si vous allez télécharger le code via une liaison réseau lente.

Utiliser un schéma basé sur des registres signifie probablement que le générateur de code de Dalvik n'a pas à travailler aussi dur pour produire un code performant. Fonctionner sur une architecture extrêmement riche en registres 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 n'incluait pas du tout de JIT. Si vous allez interpréter les instructions directement, alors un schéma basé sur des registres 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 bytecode basée 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 une VM basée sur les registres sur la diapositive 35 des diapositives de la présentation :

Enregistrer la machine

Pourquoi?

• éviter l'envoi d'instructions
• éviter les accès mémoire inutiles
• 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% d'instructions en moins
• 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, c'est "une attente générale de ce que vous pourriez trouver lorsque vous convertissez un ensemble de fichiers de classe en fichiers dex".

La partie pertinente de la vidéo de présentation commence à 25h00 .

Il existe également un article perspicace intitulé "Virtual Machine Showdown: Stack Versus Registers" de Shi et al. (2005) , qui explore les différences entre les machines virtuelles basées sur des piles et des registres.

Je ne sais pas pourquoi Sun a décidé de créer une pile JVM. Machine virtuelle Erlangs, BEAM est basée sur les registres pour des raisons de performances. Et Dalvik semble également être basé sur les registres pour des raisons de performances.

Depuis Pro Android 2 :

Dalvik utilise les registres principalement comme des unités de stockage de données au lieu de la pile. Google espère ainsi accomplir 30% d'instructions en moins.

Et concernant la taille du code:

La VM Dalvik prend les fichiers de classe Java générés et les combine dans un ou plusieurs fichiers Dalvik Executables (.dex). Il réutilise les informations dupliquées à partir de plusieurs fichiers de classe, réduisant ainsi de moitié l'espace requis (non compressé) par rapport au fichier .jar traditionnel. Par exemple, le fichier .dex de l'application de navigateur Web sous Android fait environ 200 Ko, tandis que la version .jar non compressée équivalente est d'environ 500 Ko. Le fichier .dex du réveil fait environ 50k, et environ deux fois cette taille dans sa version .jar.

Et comme je me souviens de Computer Architecture: A Quantitative Approach, nous concluons également qu'une machine de registre fonctionne mieux qu'une machine basée sur une pile.