Améliorer la JVM pour Scala

Question

Quels sont les changements à la JVM sera le plus utile à la Scala du compilateur et de l'exécution?

La dynamique des langues en bénéficieront grandement à la performance de l'introduction de l' InvokeDynamic code octet devraient arriver dans la JVM 7 et Scala sera probablement profiter de la queue de la récursivité (pas sûr si il apparaîtra dans la JVM 8 ou version ultérieure).

Quels sont les autres changements pourraient Scala, son jeu de fonctionnalités, avantages de la JVM? Ces changements sont-ils à l'horizon?

Plus précisément, existe-il des modifications à la machine qui permettrait d'améliorer les performances avec les fermetures et les fonctions comme des objets?

Answer 1

Fondamentalement, tout ce que John Rose a fait campagne pour :)

• Fixnums - Pour éliminer le coût de boxing/unboxing primitives.

• Méthode Poignées - Permettrait d'accélérer les fonctions d'ordre supérieur et permettre à la JVM pour les optimiser de manière plus efficace. SAM types peuvent parfois nécessiter un peu maladroite flip/flop entre monomorphe et megamorphic sites d'appel qui empêche l'in-lining.

• Suites À support asynchrone/conception simultanée, comme par node.js

• L'Interface d'Injection - Simplifier mixin la composition et la mise en œuvre de rôles, ainsi que d'éliminer la nécessité de générer des classes moyennes et de prise de types de construction possibles sans réflexion dans de nombreux cas.

• Queue-appel d'optimisation - Devrait être une évidence :)

La réification est souvent cité comme quelque chose qui serait à l'avantage de la Scala de filtrage, mais cela aura un coût élevé en termes d'interopérabilité, compte tenu de la différence de variance régimes que les deux langues. À ce stade, je crois que la réification peut effectivement causer plus de mal que de faire le bien.

Je pense également qu'il est déraisonnable de s'attendre à quelque chose que de casser la compatibilité descendante en Java. Qui n'est tout simplement pas qui va se passer.

Answer 2

Il ya un couple de caractéristiques de la Scala qui seraient mieux mis en œuvre dans la JVM, telle que:

• Les génériques qui sont accessibles au moment de l'exécution. Pour le moment, scalac enregistre les types de génériques que les champs cachés (si la classe en question est une affaire de classe). Les génériques dans le cas des classes inutilement cher.

• Déclaration-le site de la variance. Scala spécifie la variance des paramètres de type à la définition du site, alors que Java fait sur le site d'appel. C'est très peu probable d'obtenir corriger, cependant, car il serait briser tous les Java le code générique.

• La queue d'appel d'optimisation. Scalac pouvez faire un peu de queue appel d'optimisation sur elle-même, mais seulement dans le plus simple (auto-récursif) cas. Toute autre queue appels utilisation de la pile de l'espace comme dans la JVM.

• Suppression des pointeurs null. Scala pouvez déjà de gérer la valeur null refs avec l'Option[A], mais en raison d'être sur la JVM, la référence à l'option elle-même pourrait être nul, ou c'est le paramètre peut être null. Si vous n'obtenez pas une garantie de non-null-ness comme en Haskell.

EDIT: Ajout de la déclaration-site de la variance de la liste.

Answer 3

Types de valeur serait d'aider un peu les performances de sage pour les tuples et des classes de cas. Échapper à l'analyse permet de réduire les allocations de tas de tels objets un peu, mais pour le moment, la JVM ne peut pas inline certains appels de méthode assez agressivement ne peut donc pas éliminer les allocations de tas de ces petits objets immuables. Cela conduit à des tas de bousiller et 3-4x plus de temps d'exécution.

Types de valeur contribue également à augmenter la localité des données et de réduire l'utilisation de la mémoire. Par exemple, dans un Tableau simple[(Int, Int)] chaque entrée de ce tableau aura une surcharge de l'un pointeur + objet d'en-tête. Avec des types valeur cette surcharge peut être éliminé complètement.

Answer 4

Les utilisateurs se concentrent souvent sur InvokeDynamic - sans se rendre compte que le framework MethodHandles présente de nombreux autres avantages, même si les références de méthode fournies par MH ne sont jamais invoquées de manière dynamique.

MethodHandles est presque une forme performante de "réflexion réfléchie".

Toute langue qui fait un usage intensif de la réflexion peut très bien tirer parti de l’utilisation de MethodHandles dans son environnement d’exécution.