Ce qui est plus intéressant, c'est de savoir à quel point l'abstraction de la VM a été traduite et adaptée vers le niveau inférieur pendant l'opération.
Sur des plateformes comme Mono, la VM a été conçu pour autoriser cette compilation, tout le code intermédiaire est donc traduisible avant exécution. l'environnement d'exécution n'est alors là plus qu'un framework sous forme de bibliothèque. Le code intermédiaire reste présent pour autoriser l'introspection, mais ce n'est plus vraiment du code exécutable, plutôt un ensemble de méta-données manipulables.
Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance.
Effectivement, ces langages n'ont pas été prévu pour être compilé, et ont un modèle de machine virtuelle qui se prête mal à la compilation post-exécution. D'ailleur Java a le même problème, pendant de nombreuses années les JVM ont continués à interpréter le bytecode (même si la compilation JIT était de plus en plus présente), seul GCJ a réussi récemment à se passer de toute phase d'interprétation autorisant la compilation en code natif. C'est un des intérêt de Mono/.NET de proposer ce support en standard. D'ailleur certains en on profité pour en déduire que la plateforme .NET n'était pas adapté aux langages dynamiques. Elle n'a effectivement pas été conçu dans ce sens, mais ca reste possible comme le montre IronPython par exemple. D'ailleur la prochaine CLR-2 vise à mieux intégrer ces langages dynamiques.
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 3.
Sur des plateformes comme Mono, la VM a été conçu pour autoriser cette compilation, tout le code intermédiaire est donc traduisible avant exécution. l'environnement d'exécution n'est alors là plus qu'un framework sous forme de bibliothèque. Le code intermédiaire reste présent pour autoriser l'introspection, mais ce n'est plus vraiment du code exécutable, plutôt un ensemble de méta-données manipulables.
Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance.
Effectivement, ces langages n'ont pas été prévu pour être compilé, et ont un modèle de machine virtuelle qui se prête mal à la compilation post-exécution. D'ailleur Java a le même problème, pendant de nombreuses années les JVM ont continués à interpréter le bytecode (même si la compilation JIT était de plus en plus présente), seul GCJ a réussi récemment à se passer de toute phase d'interprétation autorisant la compilation en code natif. C'est un des intérêt de Mono/.NET de proposer ce support en standard. D'ailleur certains en on profité pour en déduire que la plateforme .NET n'était pas adapté aux langages dynamiques. Elle n'a effectivement pas été conçu dans ce sens, mais ca reste possible comme le montre IronPython par exemple. D'ailleur la prochaine CLR-2 vise à mieux intégrer ces langages dynamiques.