Ours & Hippy — le blog

Merci, c’est rigolo.

• Y’a-t-il des raisons autres que la façon dont le bytecode fonctionne pour que ce ne soit pas adapté à un langage fonctionnel ?
• Est-ce que le choix d’avoir un langage à pile et le choix d’avoir une pile par méthode influe sur les performances ?
• Tu avais besoin de ça pour écrire tes contrats en terme de bytecode ? Les contrats étaient écrits comment et où (dans le fichier en commentaire/annotation) ?

@cygal :

Je ne connais pas le bytecode Java, mais pour son équivalent .NET, la CLI (Common Language Infrastructure), "l’assembleur" possède des opérateurs pour manipuler et utiliser des objets (instanciation, appel de méthode, généricité …) ce qui fait que le modèle objet de C# est directement dicté par le modèle objet de la CLI.

Résultat, c’est plus compliqué de réaliser un langage plus fonctionnel compilant vers la CLI ou vers la JVM car la runtime est faite pour exécuter du code purement composé d’objets et de méthodes (je pense qu’il n’existe même pas d’opérateur pour appeller une fonction autre qu’anonyme en CLI).

Cependant, ça reste possible. Mais dans ce cas, il faut représanter les structures du langage fonctionnel (fonctions, records, unions, …) via des objets compatibles avec la CLI. Par exemple en F#, les fonctions ne sont pas représentées sous le même type qu’en C# (la classe générique System.Func) mais par une nouvelle classe générique FastFunc, qui permet la composition et l’application partielle de fonction (elle contient une surcharge sur l’appel ainsi que la référence vers une autre FastFunc, cette dernière étant appellée dans la surcharge, ça permet de simuler l’approche fonctionnelle des fonctions à N arguments qui sont des généralisations de fonctions à N-1 arguments).

Le problème, c’est lorsque l’on souhaite utiliser les API non fonctionnelles dans un langage fonctionnel ou utiliser les modules écrits en F# dans un autre langage non fonctionnel (un des avantages de la CLI via la standardisation du modèle objet est de pouvoir mélanger des classes écrites en différents langages dans un même projet très facilement).

Le langage fonctionnel est alors obligé de fournir un deuxième modèle objet identique à celui de la CLI (avec de vrais classes, méthodes et interfaces) pour assurer la compatibilité.

Personnellement, je trouve que ça reste intéressant de réaliser un compilateur pour la CLI ou la JVM, même pour des langages fonctionnels. Tout l’aspet générique, garbage collector, portabilite, librairie de base, modèle objet … qui sont tout de même des parties lourdes et parfois critiques ne sont plus à refaire.

J’ai discuté un peu avec rz0 de ce point. Je pense que son ton globalement plutôt pessimiste quant au support d’autres langages par la JVM sont globalement semblables à ce que raconte Raphaël : le bytecode est fortement ancré dans le modèle sémantique du langage Java, et il semble désagréable pour un langage totalement différent de devoir se plier à ce format.

Je crois que c’est aussi une forme de perfectionnisme : tout le monde aime les logiciels qui reposent sur des couches adaptées à l’usage qu’on en fait. Le choix de la JVM est un choix de facilité (convenience), pas un choix fondé sur le fait que c’est l’outil le plus adapté à la tâche. Viser la JVM c’est un peu un "hack" qui oblige à des sacrifices au niveau de la conception, pour profiter en contrepartie des services de la JVM, de la compatibilité relative avec Java, etc.

La JVM a aussi quelques soucis au niveau des fonctionnalités, par exemple la tail-récursion n’est pas supportée. Je m’apprêtais à dire que le CLR avait sans doute moins de ces défauts historique, puisque plus jeune et construit avec l’expérience durement acquise pendant le développement de la JVM, mais en y repensant il me semble me souvenir que la CLR ne supporte pas directement la tail-rec non plus.

Pour faire un début de réponse à la troisième question de Cygal (le lien entre la description du bytecode et les contrats), oui, le travail de rz0 se place en partie au niveau directement du bytecode, et il a prévu d’en parler à l’avenir. Motivé, peut-être, par mes efforts de communication sur mon stage ? :-’

Enfin, je me pose une question : on entend pas mal parler d’un modèle de sécurité par "inspection de la pile", qui aurait été très apprécié par les utilisateurs de la JVM, mais qui aurait aussi des défauts de conception. Qu’est-ce que c’est, et est-ce qu’il est prévu d’en parler ?

@bluestorm:

La CLI a une instruction tail pour les appels terminaux, mais il n’est pas optimisé par la CLR avant la version 4.0 de .NET. Par contre, ce n’est pas encore le cas pour Mono.

Par contre, on peut faire l’optimisation au niveau du compilateur en amont, c’est ce qui se passe pour F#.

@Cygal Pour ce qui est de mon travail à proprement parler, oui, je touille pas mal de bytecode, mais seulement pour injecter les contrats ; la compilation du code des contrats elle-même utilise javac directement, avec une technique de stubbing assez gore. Comme blue l’a dit, je vais consacrer un ou deux articles rien qu’à ça donc vlà. Autrement, les contrats sont implémentés en tant qu’annotations.

Pour ce qui est des performances, hum, l’usage d’une pile plutôt que de registres implique que les opérations se passent dans une zone de mémoire adressable (il faut pouvoir dire « on prend le truc au sommet de la pile », genre, et le sommet de la pile, il change). Ça peut tout à fait se faire, y compris en hardware (genre avoir les N premiers octets de la pile mappés sur de la mémoire rapide type registres du CPU). En revanche, simuler une pile sur une machine à registres non adressables (genre x86), c’est bof bof. Ceci dit, on peut compiler le code pour machine à pile en code natif efficace (ce que font les JIT), pourvu que l’on puisse calculer statiquement l’occupation de la pile (c-à-d qu’il n’y a pas d’opération magique qui peut consommer un nombre indéterminé d’opérandes sur la pile, p.ex.), mais d’une certaine manière, ça demande d’anéantir l’idiome de base. :p

Une transformation simple d’opérations à pile en opérations à registres, c’est de considérer que ce qu’il y a sur la pile à un instant donné représente un ensemble de variables : empiler, c’est créer une variable, désempiler, c’est marquer sa fin de vie. Avec ça, on obtient un graphe de durées de vie des variables, et on fait sa tambouille d’affectation de registres classique.

@Raphael Il me semble bien que sans une construction de saut non local, il y aura toujours des cas où la tailrec ne pourra pas être optimisée en saut local (p.ex. en boucle, quoi) par le compilo. Un bête truc du genre :

let g f x = f x

Cela n’a, on est d’accord, aucun intérêt, mais ici l’appel est terminal, pourtant, si on compile de manière séparée, la destination du saut est inconnue donc on ne peut pas déplier l’appel localement.

Une manière de faire, qui n’est pas viable en pratique (’fin je pense), ce serait de convertir (au niveau du compilo) toutes les fonctions en trampolines. Au lieu d’avoir le corps de la fonction directement, on aurait une boucle qui appellerait une fermeture à chaque itération (retournant un truc du genre type r = Result of t | Cont of (unit -> r)), en commençant par la fonction de départ.

@bluestorm Pour ce qui est de la vérification de la pile, bah, disons que c’est lourd. :p Ça demande une analyse de flots et tout, donc c’est pas rien ; dans Java 7 et au-delà, ils veulent obliger les compilos à précalculer les valeurs à vérifier, mais du coup ça rend la réécriture du bytecode très laborieux… parce que l’agent qui récrit doit faire l’analyse de flots lui-même. Heureusement ya des libs qui font ça, mais Sun/Oracle devrait clairement offrir des outils pour faire ça, à mon avis, au lieu de laisser les gens se débrouiller…