États et transitions

Le benchmark implémenté (décrit Section 4.1) a permis d'identier les diérents états possibles du site d'appel générés par C2 en jouant sur les diérents paramètres impactant l'état du code (cf. Figure 4.3). Ces diérents états sont les suivants :

1. Monomorphique-AHC (généré seulement pour les appels virtuels) ; 2. Monomorphique ;

3. Bimorphique ;

4. Polymorphique-domination3;

5. Etats polymorphiques3: polymorphique-CI, dispatch-virtuel ou dispatch-d'interface.

3Polymorphique, signiant "plusieurs formes", inclut normalement le cas particulier de deux formes à savoir bimorphique. Dans cette étude le terme polymorphique exlus le cas bimorphique comme ce dernier est un cas spécique. Pour lever cette ambiguïté le terme mégamorphique est parfois utilisé à la place de polymorphique pour signier "strictement plus de deux formes".

L'état 1 utilise l'AHC (Analyse de Hiérarchie de Classe) [31] pour déterminer si le site d'appel est monomorphique. C'est le cas si une unique implémentation de la méthode vir-tuelle est chargée par le chargeur de classe4.

Les états 2, 3, 4 sont des états optimisés utilisant les résultats du proling sur le type du receveur. Plus précisément, l'état 2 survient lorsque l'AHC a déterminé plusieurs méthodes cibles potentielles mais que le proling ne montre qu'un seul type de receveur impliqué au niveau du site d'appel. L'état 3 survient lorsque le proling a détecté deux types de rece-veur impliqués et l'état 4 lorsqu'il a détecté plus de deux types impliqués, mais que l'un domine en terme de fréquence. Le proling du type du receveur est activé par défaut et contrôlé via le paramètre -XX:UseTypeProfile. Contrairement à l'AHC qui est globale à tous les sites d'appels, le proling est local à chacun d'entre eux.

L'état 5 est l'état polymorphique généré lorsque le proling ne peut optimiser le site d'ap-pel ou bien qu'il est désactivé. Il possède deux sous-états. Un premier, polymorphique-CI, utilisant un cache d'inline (CI) [71] et un second utilisant du dispatch et qui dière dans le cas d'un appel virtuel (dispatch-virtuel) ou d'un appel d'interface (dispatch-d'interface). 4.2.1.1 États naux

Les états naux sont les états pour lesquels l'exécution ne déclenche pas de transition vers un autre état5. La Figure 4.4 illustre les diérents états et leurs transitions. L'état in-terprété est l'état initial. Les transitions après compilation vers l'état inin-terprété surviennent lorsque le code du site d'appel est invalidé. Il y a deux raisons qui causent l'invalidation du site d'appel, soit par désoptimisations successives lorsque le code utilise les hypothèses de proling, soit par le chargeur de classe lorsque le code est généré par AHC.

Le diagramme état-transition est considéré en mode non-étagé (cf. Section 3.2.2). Dans ce cas le proling a lieu uniquement en mode interpréteur et l'utilisation des informations se fait à la compilation du code par C2. En mode étagé, des états intermédiaires entre les états compilés et interpréteur apparaîtraient avant d'atteindre les états compilés par C2 (cf. Section 2.3.2.3 Chap. 2). On admet que pour l'exécution d'une même distribution le code résultant après warmup en non-étagé et étagé est identique.

4.2.1.2 Prise en compte de l'inlining

Comme justié dans la mise en ÷uvre du benchmark mesurant les performances du polymorphisme (cf. Section 4.1), l'inlining n'est pas activé pour les tests. Les états consi-dérés et énumérés précédemment sont donc ceux obtenus lorsque l'inlining est désactivé. Les sites d'appel générés lorsque l'inlining est désactivé sont cependant similaires à ceux lorsque ce dernier est activé. Cette similarité signie que le site d'appel sans inlining est

4Notons que l'AHC fonctionne dans ce cas par méthode et non par classe. Plus précisément si une classe lle est chargée mais qu'elle ne surcharge pas la méthode

5Une méthode contenant un site d'appel dans un état nal peut néanmoins être invalidée pour d'autres raisons que le site d'appel

1 ₄

5.

2 3

5.

0

Fig. 4.4: Diagramme des états/transitions d'un site d'appel invokevirtual ou invokeinterface en mode non-étagé

équivalent au site d'appel avec inlining excepté que le corps des méthodes inlinées est rem-placé par l'instruction d'appel de la méthode. La Table 4.1 résume l'eet de l'inlining sur le site d'appel lorsqu'il est activé. Considérant uniquement le coût des méthodes à vide (cf. Figure 4.2), l'inlining s'avère crucial pour garantir de bonne performance pour des appels de méthodes de faible complexité ; indépendamment des optimisations de contexte, en considérant uniquement l'élimination coup d'appel à vide. Ainsi l'écart de performance entre les sites d'appel avec inlining et sans doit être plus important dans un benchmark ou l'inlining est activé.

État du site d'appel Eet de l'inlining

Monomorphique-AHC

Monomorphique ^{Le JIT tente d'inliner l'unique méthode ren-}contrée Bimorphique ^{Les JIT tente d'inliner les deux méthodes ren-}_contrées Polymorphique-domination ^{Le JIT tente d'inliner la méthode associée au}_{type dominant} États polymorphiques

(avec CI ou dispatch) ^{Aucun eet}

Tab. 4.1: Eet de l'inlining sur les sites d'appel lorsqu'il est activé. En vert les états bénéciant de l'inlining et en rouge les états invariant avec l'activation de l'inlining. Le code généré pour les sites d'appels inlinés dière par le fait que l'instruction d'appel de méthode est remplacée par le corps de méthode ; le dispatch étant inchangé