web-dev-qa-db-fra.com

Pourquoi la JVM ne peut-elle pas être utilisée à la place de WebAssembly?

D'après ce que j'ai compris, JavaScript ne peut pas être compilé à l'avance en raison de sa nature dynamique. L'interprétation et la compilation juste à temps ont donc lieu au moment de l'exécution, ce qui affecte les performances JavaScript. WebAssembly entre donc en scène. Les langues peuvent être compilées à l'avance dans un format intermédiaire (WASM). Cela donne de bonnes performances car il y a moins de temps d'exécution.

Ma question est pourquoi JVM ne peut pas être utilisé à la place de WebAssembly VM. Java compilé en format intermédiaire (bytecode). Ce code d'octet peut être donné au navigateur et JVM peut l'exécuter. JVM prend également en charge JIT qui permet d'atteindre des performances quasi natives.

Alors, quel est le besoin d'un nouvel assemblage Web. Pourquoi la JVM ne peut-elle pas être intégrée dans le navigateur et atteindre des performances élevées en tirant parti de la langue Java Java la plus populaire).

javascriptjvmwebassembly
9
Jawahar

Il existe de nombreuses raisons pour lesquelles la JVM n'a pas été considérée comme un runtime approprié à la place de WebAssembly ...

  • WebAssembly a été conçu avec une livraison sur HTTP et basée sur un navigateur. Pour cette raison, il prend en charge la compilation en streaming - c'est-à-dire que vous pouvez commencer à compiler le code pendant le téléchargement.
  • WebAssembly a été conçu pour avoir des temps de compilation rapides (résultant en des pages Web qui se chargent rapidement), ceci est soutenu par des règles de validation très simples par rapport aux langages Java/JVM).
  • WebAssembly a été conçu avec le concept d'un environnement `` hôte '', c'est-à-dire le navigateur.
  • WebAssembly a été conçu pour être sûr et simple, minimisant la surface d'attaque globale.
  • WebAssembly a été conçu pour prendre en charge un grand nombre de langages (C, C++, Rust, ...), alors que la JVM était initialement conçue pour un seul langage, Java.

À titre d'observation générale, WebAssembly a été conçu pour prendre en charge plusieurs langues sur le Web. La machine virtuelle Java a été conçue pour prendre en charge Java sur le bureau. Elle n’améliore ni l’un ni l’autre dans un sens plus général.

Enfin, la JVM a été intégrée au navigateur (Java Applets), mais cela n'a finalement pas fonctionné!

18
ColinE

Une citation des Objectifs de haut nivea de WebAssembly:

un produit minimum viable (MVP) pour la norme avec à peu près les mêmes fonctionnalités que asm.js, principalement destiné à C/C++;

Donc, leur objectif initial était d'exécuter le programme C/C++ dans un navigateur Web, pas d'exécuter Java code.

2
Bumsik Kim

La plupart du temps d'exécution de JS est consacré à envoi du code du serveur au client. Le bytecode a tendance à être plus grand que le code source réel derrière, donc la compilation en bytecode n'accélère pas nécessairement les choses.

JS lui-même est déjà exécuté assez rapidement dans la plupart des cas (la compilation JIT n'est pas seulement effectuée par la JVM). Dans ces rares cas, les performances étaient vraiment importantes (manipuler de grands ensembles de données, faire beaucoup de calculs, par exemple les moteurs de jeu) JS est lent en raison de sa nature dynamique (nommément collection garbagge, fermetures, ...). C'est exactement ce que WASM résout, il fonctionne sans collection de garbagge et peut donc être beaucoup plus rapide dans ces cas spécifiques.

La JVM n'est pas le bon outil pour le travail ici.

1
Jonas Wilms