Quels sont les fondamentaux / Feature différences architecturales entre le BEAM et machine virtuelle Java?

Question

Quels sont quelques-unes des caractéristiques / différence architecturale fondamentale entre le BEAM et JVM?

1. Oui je sais: on était à l'origine construit autour java et l'autre construit autour Erlang
2. Je comprends la machine virtuelle Java (un peu) et que vous souhaitez comparer leurs structures
3. Par exemple, je sais que la machine virtuelle Java a un mondial GC et BEAM a un processus par

Answer 1

Tout d'abord, Beam est une machine à registre, pas une machine à pile. Comme le WAM pour Prolog, il utilise « X-registres » qui sont entrées normales (mis en œuvre sous forme de tableau dans C) et « Y-registres » qui sont des noms pour les fentes de la fiche locale d'activation de fonction (le « bloc d'appels ») sur la pile. Il n'y a pas d'instructions de manipulation de la pile.

En second lieu, il y a des instructions pour allouer rapidement quelques mots de la mémoire de tas, pour initialiser tuples et d'autres structures de données sur le tas, pour sélectionner des éléments de tuples, etc. JVM se concentre sur les objets, et a une « nouvelle » opération qui cache les détails de l'allocation de mémoire et l'initialisation de base.

Le faisceau a une instruction pour décrémenter le « compteur de réduction » du processus et de décider s'il est temps de céder à laisser un autre terme de processus. JVM d'autre part, comporte des instructions de synchronisation des threads.

Une différence importante est que BEAM a des instructions d'appel de queue, qui ne dispose pas JVM.

Enfin, pour les deux BEAM et machine virtuelle Java, le jeu d'instructions utilisé dans les fichiers objet sont vraiment seulement un format de transport. L'émulateur BEAM réécrit les instructions du fichier dans une version interne avec de nombreuses instructions optimisées cas spéciaux (qui peut varier d'une version à l'autre). Alternativement, vous pouvez compiler en code natif. La plupart des JVMs font la même chose.

Answer 2

D'autres points intéressants sont:

1. Les processus sont citoyens BEAM et sont gérés par la machine virtuelle elle-même alors que les délégués JVM leur gestion à l'OS. Cela permet au faisceau de gérer (créer, supprimer, changement de contexte, ...) très rapidement et, par conséquent, être en mesure de gérer des centaines de milliers de processus par rapport à quelques centaines de fils de java sur une machine raisonnable.

2. Le BEAM, les communications inter-processus est basé sur l'échange de messages qui élimine la plupart sinon toutes les situations qui peuvent conduire à une condition de course. Sur Java, vous devez synchroniser les threads qui est difficile et bug sujets.

3. Un point important est que la collecte des ordures se fait sur une base par processus dans le faisceau alors qu'il est un processus global dans la machine virtuelle Java. L'impact est qu'un GC sur la machine virtuelle Java peut geler toute VM pour peut-être quelques secondes tout au BEAM chaque processus doit donner certains de ses opérations d'exécution (réductions) au GC sans impact sur les autres processus.

Récemment, de nouvelles bibliothèques comme VertX (je ne sais pas vraiment

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow