L'exécution du bytecode produit par le compilateur OCaml passe par l'utilisation d'une machine virtuelle (ZAM). Il se trouve que cette machine est écrite dans le langage C. Il est donc a priori facile pour cette machine d'appeller du code C défini par l'utilisateur (ManouryChaillouxPagano:DAOC:2000, LeroyEtAl:OCamlMan:intfc).

Les instructions de la famille C_CALL prennent comme argument un pointeur de fonction indiquant la fonction C à exécuter.

L'utilisateur peut déclarer l'utilisation d'une fonction C grâce au mot clé external. Il précise le type de la fonction, ainsi que son nom dans le code C (voir 1).

type c_list

external empty_c_list : unit -> c_list = "empty_c_list"
external cons_c_list : int -> c_list -> c_list = "cons_c_list"
external print_c_list : c_list -> unit = "print_c_list"

let _ =
  let l = empty_c_list () in
  let l1 = cons_c_list 42 (cons_c_list 21 l) in
  print_c_list l;
  print_c_list l1

Les fonctions C doivent bien sûr être définies dans un fichier .c. Ici le fichier clist.c est détaillé dans 2.

#define CAML_NAME_SPACE
#include <caml/mlvalues.h>

typedef struct _List {
  int data;
  struct _List *next;
} List;

CAMLprim value empty_c_list(value u) { [...] }

CAMLprim value cons_c_list(value iv, value lv) { [...] }

CAMLprim value print_c_list(value lv) { [...] }

L'exécutable clist.byte peut être compilé avec la série de commande suivantes:

# Compile clist.c vers une bibliotheque clist.a
gcc -o clist.o clist.c -I~/.opam/default/lib/ocaml
ar rcs clist.a clist.o
# Compile clist.ml vers un executable, en utilisant la bibliothèque clist.a
ocamlc -c -o clist.cmo clist.ml
ocamlc -o clist.byte -custom clist.cmo -cclib -L . -cclib -lclist

Les valeurs OCaml sont encapsulées dans le type value. Le fichier caml/mlvalues.h fourni des accesseurs / constructeurs permettant de les manipuler. Une valeur peut être de deux formes : entiers (non alloués) et pointeur vers un "bloc" alloué dans le tas. Les blocs sont tagués, ce qui permet de reconnaître leur contenu, et contiennent un certain nombre de champs.

Il faut vérifier dynamiquement la forme de la valeur ! On perd la sécurité du système de types.

Comme vous l'avez étudié dans un cours précédent, les langages de haut-niveau tels qu'OCaml ou Java bénéficient souvent d'un mécanisme de gestion de la mémoire automatique (GC, pour garbage collector ou glaneur de cellules). Ce n'est pas le cas du langage C, où la libération de la mémoire est à la charge du programmeur. Pour que ces deux modèles coopèrent, il faut que le code C et sa gestion manuelle donne beaucoup d'informations aux GC, pour que celui-ci puisse fonctionner correctement.

Les variables présentes sur le tas et qui donc doivent être manipulées par le GC sont celles ayant le type value, comme on l'a vu plus haut. En particulier, les blocs doivent être effectivement alloués sur le tas afin de pouvoir être collectés par le GC plus tard. Pour ce faire, on utilise la fonction caml_alloc(size, tag) qui alloue un bloc de taille size, avec le tag donné. Cependant, on s'aperçoit tout de suite d'une difficulté : si on peut allouer dans le tas, alors il est tout à fait possible que le GC se déclenche pendant l'exécution d'une fonction externe. Il va donc falloir s'assurer que le GC dispose des bonnes informations, même au milieu d'une fonction externe, afin de ne pas libérer de la mémoire utilisée.

Une fonction C destinée à être appellée par la FFI doit toujours commencer par l'une des macros de la famille CAMLparam (CAMLparam0(), CAMLparam1(x), CAMLparam2(x, y),…). Cette macro alloue un cadre sur la pile d'appels de fonctions, et y place les variables paramètres de la fonction. Ainsi, ces pointeurs seront pris en compte comme racines si le GC se déclenche pendant l'exécution de la fonction, et les blocs associés ne seront pas libérés. De la même manière, les variables locales à la fonction doivent aussi être enregistrées dans le cadre. Cela peut être fait via la famille de macros CAMLlocal (CAMLlocal1(x), …). On utilise ces macros à la place de la déclaration d'une variable locale (par exemple value v; est remplacée par CAMLlocal1(v)).

Bien sûr, aucune de ces règles ne sont vérifiées à la compilation du programme, ce qui induit encore un risque d'erreur de la part du programmeur. Il faut donc être particulièrement délicat.

CAMLprim value cons_c_list(value iv, value lv) {
  CAMLparam2(iv, lv);
  CAMLlocal1(nv);

  // Get the C values back
  List *l = List_val(lv);
  int i = Int_val(iv);

  List *nl = malloc(sizeof(List));
  nl->data = i;
  nl->next = l;

  // Return the new list, packed as a caml value
  nv = caml_alloc(1, Abstract_tag);
  List_val(nv) = nl;
  CAMLreturn(nv);
}

Dans la figure 5, on montre un exemple de l'utilisation de toutes ces macros pour bien définir la fonction qui ajoute un entier en tête d'une liste chainée en C.

Il est également possible de déclencher des exceptions depuis le code C. Pour les exceptions "classiques" Failure et Invalid_argument, les fonctions caml_failwith(s) et caml_invalid_argument(s) sont fournies.

Utiliser une exception définie par l'utilisateur est plus complexe. L'utilisateur doit enregistrer l'exception sous un nom, qui permettra de l'identifier dans le code C.

Par exemple, on enregistre l'exception Error:

exception Error of string
let _ = Callback.register_exception "my_error" (Error "dummy")

On note que la chaîne passée au constructeur Error ne sera pas prise en compte quand l'exception sera levée, et ne sert qu'à produire une expression du bon type. On peut alors lever l'exception depuis le code C. Pour cela, on récupère la valeur identifiée grâce à caml_named_value. Plusieurs fonctions permettent alors de lever l'exception :

• caml_raise_constant(e) pour une exception sans paramètre
• caml_raise_with_arg(e, v) pour une exception avec un paramètre
• caml_raise_with_args(e, n, v) pour une exception à n arguments (v est un tableau de value de taille n)
• caml_raise_with_string(e, msg) pour une exception avec comme seul paramètre une chaîne de caractères.

Ici on peut utiliser cette dernière fonction:

void raise_error(char * msg) {
  caml_raise_with_string(*caml_named_value("my_error"), msg);
}

Jusqu'ici, on a vu comment écrire du code C et l'appeler depuis OCaml. Cependant, il est aussi possible de rappeler du code OCaml depuis une fonction C. En effet, OCaml permettant d'écrire des fonctions d'ordre supérieur (prenant des fonctions en paramètre), on peut supposer une fonction avec la signature suivante : apply : ('a -> 'b) -> 'a -> 'b dont le rôle est simplement d'appliquer son premier paramêtre à son deuxième, est de renvoyer le résultat. Comment écrire cette fonction en C ? Très simplement en utilisant le mécanisme de "callbacks". On définit la fonction apply en C. Le premier de ses paramètres est la fermeture (closure) passée à la fonction. Cette fermeture peut être appelée grâce à la fonction caml_callback. Celle ci lance tout simplement une nouvelle instance de l'interpréteur OCaml, sur le code de la fermeture.

CAMLprim value apply(value closure, value arg) {
  CAMLparam2(closure, arg);

  CAMLreturn(caml_callback(closure, arg));
}

external apply : ('a -> 'b) -> 'a -> 'b = "apply"

let _ =
  print_int (apply (fun x -> x * 2) 21)

Le slogan "Write once, run anywhere" créé par Sun Microsystems pour promouvoir le langage Java illustre une idée importante : une machine virtuelle permet de factoriser les efforts des développeurs lors du portage vers différentes architectures, systèmes d'exploitations, etc… En théorie, un programme Java peut être exécuté sur n'importe quel environnement, pour peu que la JVM y ait été portée. Cette machine virtuelle est l'une des clés de la réussite industrielle du langage Java. Cette réussite est d'ailleurs quantifiée par un nouveau slogan (que vous avez sûrement déjà lu) : "3 Billion Devices Run Java", qui fait état de la très large installation de la JVM.

Cette base d'installation conduit à la réalisation suivante : d'autres langages ciblant la même machine virtuelle bénéficient alors de la même base d'installations. De nombreux langages autres langages peuvent donc tirer partie de la JVM. Certains sont écrits spécifiquement avec la JVM en tête (Clojure, Scala, Kotlin…), mais des implémentations utilisant la JVM ont aussi été développées pour des langages pré-existants (Jython pour Python, OCaml-Java pour OCaml…).

L'utilisation d'une plateforme commune impose des contraintes sur le design ou sur la compilation des langages, mais elle rend aussi beaucoup plus simple l'interopérabilité entre langages. Plus bas, on voit comment le langage Clojure interagit avec Java.

Nous avons vu dans précédemment qu'il était facile de faire communiquer plusieurs langages exécutés par une machine virtuelle commune. Il se trouve que tous les navigateurs web modernes embarquent une machine virtuelle pour l'exécution du langage JavaScript.

Si cette machine était d'abord destinée spécifiquement à l'exécution de programmes écrits en JavaScript, de nombreux langages compilant vers JavaScript ont depuis vus le jour (Typescript, Clojurescript…).

Pour pouvoir exécuter des programmes existants dans le navigateur, des compilateurs de langages existants vers JavaScript sont aussi disponibles. On verra ici l'exemple de Js_of_ocaml (Vouillon:JsOfOCaml:2014). Ce compilateur accepte en entrée le bytecode d'un programme OCaml. L'inconvénient de ce procédé est que le code JavaScript produit en sortie du compilateur n'est pas lisible. L'avantage est que, le bytecode OCaml étant assez stable (il est assez rare qu'une instruction y soit ajoutée ou retirée), Js_of_ocaml peut donc aisément rester compatible avec les versions récentes d'OCaml. Par ailleurs, Js_of_ocaml peut également bénéficier des optimisations déjà opérées par le compilateur OCaml.