-
Notifications
You must be signed in to change notification settings - Fork 2
VMKit integration
Ayant réutilisé le plus possible le code de l'interpréteur OCaml, le choix a été fait de garder une représentation des données compatible avec celle d'OCaml, nous évitant ainsi de devoir créer une interface vers le code OCaml et nous permettant de le réutiliser tel-quel.
Notre représentation diverge de celle d'OCaml puisque, n'utilisant pas de pile explicite, nous avons besoin, par exemple pour les closures, de stocker des informations suplémentaires. Dans l'interpréteur, ces informations sont stockées dans la pile.
Nos données étant rajoutées à la fin de l'objet, il pourra être manipulé par du code OCaml qui ne verra pas la différence.
Un objet VMKit possède par défaut un entête et une table virtuelle. L'entête est utilisé par le GC, alors que la table n'est utilisée que par la machine virtuelle si celle-ci en a besoin. Elle est initialement vide.
Il possède aussi une fonction tracer (seulement déclarée, à implémenter) qui
doit permettre de trouver tous les objets référencés dans l'objet courant.
VMKit n'ayant servit pour l'instant qu'à construire des machines virtuelles pour des langages objets et donc assez semblables (Java et C#), le modèle objet VMKit fait d'importantes suppositions et n'est, en l'état, pas compatible avec notre représentation basée sur celle d'OCaml.
Deux solutions existent:
-
Modifier notre modèle objet: Il ne sera plus compatible avec le modèle OCaml, ce qui amène à plusieurs modifications de notre générateur.
-
Modifier le modèle VMKit: Gaël Thomas nous a proposé la possibilité de modifier le modèle objet de VMKit, puisqu'à terme ce dernier devrait posséder une représentation des données totalement neutre.
L'entête étant utilisé par le GC, on ne peut s'en passer. On peut en revanche le masquer en faisant pointer chaque référence d'un objet non pas sur l'entête mais juste après, sur le deuxième mot, de la même manière que les objets OCaml. Ainsi il deviendrait invisible aux yeux de qui ne voudrait le voir, mais toutes les utilisations de cet entête devraient être modifiées pour prendre en compte ce changement.
La table virtuelle n'est en revanche pas utilisée par MMTk et pourrait donc, en théorie, être déplacée dans J3 et ne plus polluer le modèle objet VMKit.
Si ces deux modifications sont faites alors la représentation des données actuelle pourrait être préservée.
L'autre solution est de prendre en compte l'entête et la table virtuelle dans notre modèle.
Comme nous ne nous servons pas de la table virtuelle, celle-ci aura une taille fixe. Il nous suffirait donc de réserver un emplacement au début de chaque objet pour l'entête et la table.
Nous aurions donc la structure suivante:
/-----------|--------|-----------|-----\
| VMKit Hdr | VTable | OCaml Hdr | ... |
\-----------|--------|-----------|-----/
Ce changement nous oblige à effectuer des modifications: cette structure n'est plus compatible avec la représentation OCaml.
Une manière de remédier à ce problème est de modifier les sources OCaml directement: Tous les accès aux différentes parties de l'objet (entête, environnement, etc...) se font à travers des macros. Ainsi il serait possible de seulement modifier celles-ci, pour que l'entête VMKit et la table virtuelle soient invisibles et ne posent aucuns problèmes.