c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?
Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement. Par exemple quand tu as une interface X et une référence x vers un objet de type X, quand tu appelles une méthode disons f (x.f) la méthode réellement exécutée est choisie dynamiquement, ce qui pose des tas de problèmes (pas d'inline, look up dans une table, etc.). Une VM peut faire de l'analyse de code et supprimer le dispatch dynamique dans certaines conditions. D'autres exemples sont la gestion fine du garbage collector (réglage de certains paramètres au vol) ou encore la façon donc la VM .NET engendre les templates au vol (avec partage du code si nécessaire et spécialisation si ça peut apporter quelque chose en terme de performances).
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc. En fait, il y a assez peu de choses qu'on ne peut pas faire sans VM, à condition d'intégrer un runtime dans l'exécutable, c'est à dire une sorte de bibliothèque chargée de fournir de façon transparente certains services. C'est ce système qui permet de compiler OCaml en natif.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM. L'intérêt d'une VM, c'est bien qu'elle a accès à un code de haut niveau (le code de la VM). Elle peut donc prendre des décisions fines sur ce code qu'elle ne pourrait pas prendre à partir d'un code objet, parce que le bytecode Java ou .NET est de plus haut niveau, tout simplement. Timaniac a quand même raison sur un point (ça lui arrive), c'est que la sécurité vient en partie de ce code de haut niveau qui est en général vérifiable : la VM peut s'assurer qu'il ne contient pas de buffer overflown et d'autres bugs qui pourraient mettre en péril son modèle de sécurité. Ce n'est pas parfait, mais ça offre un niveau de sécurité largement supérieur à celui des plugins écrits en C pour Gimp, par exemple.
Au final, le principal intérêt des VMs ce sont justement les performances, ce qui est assez paradoxal. L'autre intérêt, c'est la programmation en couche : développer une VM de base, ce n'est pas très difficile (il existe une bonne dizaine de JVM open source, par exemple), car ça reste de bas niveau. Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur, par exemple. En gros, on a donc intercalé un niveau d'abstraction entre le hardware et le compilateur, ce qui est assez cool.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
[^] # Re: C# et le libre...
Posté par boubou . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 4.
Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement. Par exemple quand tu as une interface X et une référence x vers un objet de type X, quand tu appelles une méthode disons f (x.f) la méthode réellement exécutée est choisie dynamiquement, ce qui pose des tas de problèmes (pas d'inline, look up dans une table, etc.). Une VM peut faire de l'analyse de code et supprimer le dispatch dynamique dans certaines conditions. D'autres exemples sont la gestion fine du garbage collector (réglage de certains paramètres au vol) ou encore la façon donc la VM .NET engendre les templates au vol (avec partage du code si nécessaire et spécialisation si ça peut apporter quelque chose en terme de performances).
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc. En fait, il y a assez peu de choses qu'on ne peut pas faire sans VM, à condition d'intégrer un runtime dans l'exécutable, c'est à dire une sorte de bibliothèque chargée de fournir de façon transparente certains services. C'est ce système qui permet de compiler OCaml en natif.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM. L'intérêt d'une VM, c'est bien qu'elle a accès à un code de haut niveau (le code de la VM). Elle peut donc prendre des décisions fines sur ce code qu'elle ne pourrait pas prendre à partir d'un code objet, parce que le bytecode Java ou .NET est de plus haut niveau, tout simplement. Timaniac a quand même raison sur un point (ça lui arrive), c'est que la sécurité vient en partie de ce code de haut niveau qui est en général vérifiable : la VM peut s'assurer qu'il ne contient pas de buffer overflown et d'autres bugs qui pourraient mettre en péril son modèle de sécurité. Ce n'est pas parfait, mais ça offre un niveau de sécurité largement supérieur à celui des plugins écrits en C pour Gimp, par exemple.
Au final, le principal intérêt des VMs ce sont justement les performances, ce qui est assez paradoxal. L'autre intérêt, c'est la programmation en couche : développer une VM de base, ce n'est pas très difficile (il existe une bonne dizaine de JVM open source, par exemple), car ça reste de bas niveau. Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur, par exemple. En gros, on a donc intercalé un niveau d'abstraction entre le hardware et le compilateur, ce qui est assez cool.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.