Quels sont les inconvénients de cibler la JVM au lieu de x86 ?

Question

Je suis en train de développer une nouvelle langue. Mon objectif initial était de compiler en x86 natif pour la plateforme Windows, mais maintenant j'ai des doutes.

J'ai vu quelques nouveaux langages cibler la JVM (notamment Scala et Clojure). Bien sûr, il n'est pas possible de porter tous les langages. facilement à la JVM ; cela peut entraîner de légères modifications du langage et de sa conception.

Après avoir posé cette question, j'ai même douté davantage de cette décision. Je connais maintenant quelques arguments "pro" JVM. La question originale était : Est-ce que cibler la JVM est une bonne idée, quand on crée un compilateur pour un nouveau langage ?

Mise à jour de la question : Quels sont les inconvénients de cibler la JVM au lieu de x86 sous Windows ?

Answer 1

Vous pouvez envisager de cibler la LLVM plutôt que la JVM. La LLVM peut être utilisée pour cibler un certain nombre d'architectures, y compris x86.

La portabilité ne se limite pas à la simple prise en charge des processeurs, mais la LLVM peut être d'un grand secours et vous permettre d'obtenir du code natif, si vous le souhaitez.

Answer 2

Le ciblage de la JVM est une approche assez éprouvée. Le fait que Clojure, Scala, JRuby et de nombreuses autres langues qui l'ont fait avec succès devraient vous rassurer.

Mon opinion générale est que la JVM est probablement la meilleure cible actuellement pour les langages nouveaux/expérimentaux, en particulier si vous espérez obtenir une capacité multiplateforme tout en profitant d'un compilateur JIT vraiment fantastique et d'une multitude de bibliothèques très puissantes.

Cela dit, les principaux inconvénients que vous pouvez rencontrer en ciblant la JVM sont à mon avis les suivants :

• Absence de support de la récursion de queue au niveau du bytecode. Il existe des moyens de contourner ce problème (voir par exemple la forme spéciale "recur" de Clojure) mais c'est gênant pour certaines implémentations de langage, en particulier les langages fonctionnels. Ce problème sera probablement corrigé dans les futures versions de Java.

• C'est un peu évident, mais vous devez avoir une JVM installée sur votre client. Ce n'est généralement pas un problème de nos jours, mais il y a encore des cas où cela peut être délicat.

• Les primitives (int, long, float etc.) en Java se comportent différemment du reste du système d'objets. Encore une fois, vous pouvez contourner ce problème, mais cela représente une difficulté supplémentaire pour les implémenteurs du langage.

Quelques liens potentiellement utiles/intéressants :

• Cadre d'analyse et de manipulation du bytecode ASM . C'est un outil formidable, Je crois que c'est ce que Clojure utilise sous le capot.

• Code source Clojure

Answer 3

Si vous créez un langage pour la JVM, vous avez également le grand avantage d'avoir à vos pieds une énorme bibliothèque, qui peut être facilement utilisée à partir de votre langage. Ce n'est très probablement pas le cas si vous compilez pour x86. Je suppose que vous ne permettrez pas d'inclure, par exemple, des en-têtes C dans votre langage sans disposer d'un analyseur syntaxique C.

C'est pour cette raison que Scala, Groovy et autres connaissent un tel succès.

Au stade actuel de développement de la JVM, et avec les nouvelles améliorations apportées à la prise en charge des langages de script, je me contenterais de cibler la JVM, car il y a de fortes chances que votre langage soit exécuté plus rapidement qu'avec toutes les bibliothèques d'exécution que vous pourriez vous créer.

Answer 4

Vous ne devez cibler la JVM que si vous souhaitez que la partie "runtime" de votre code soit totalement dépendante d'un code tiers et que vos utilisateurs doivent l'installer, y En effet, la JVM fournira des fonctionnalités substantielles que vous ne pouvez raisonnablement pas développer vous-même ou demander aux gens d'étendre dans ce but (par exemple, les en-têtes de système d'exploitation en C++), y vous vous contentez de la JNI comme interface avec le code natif (et donc avec d'autres codes gérés comme .NET).

En définitive, cela dépend totalement des ressources dont vous disposez et de la manière dont vous imaginez l'interopérabilité des langues. Si vous avez l'intention d'utiliser la JVM pour fournir de nombreuses fonctionnalités, et que vous êtes heureux que l'interopérabilité soit horrible, alors utilisez-la. Dans le cas contraire, je pense que vous devriez reconsidérer votre décision.