La coloration de méthodes ou d’attributs est une généralisation de la coloration de classes : en effet, la coloration de classes est une coloration de méthodes pour laquelle il y a une et une seule méthode introduite dans chaque classe. On peut en plus colorer simultanément les méthodes et les classes, ce qui revient simplement à ajouter une introduction de méthode à chaque classe : le problème ne change pas, à moins de vouloir allouer une demi-place pour la classe dont l’identifiant nécessite moins de place qu’une adresse.
3.1 Propriétés : colorations parfaites
Lorsque la coloration de classes est parfaite et en typage statique uniquement1, il en est de même pour la coloration des méthodes et des attributs, dont le calcul se ramène alors à celui de la coloration de classes.
On peut d’abord noter que deux méthodes (resp. attributs) sont en conflit si elles appartiennent à la même classe, sans que les classes qui les introduisent soient sous-classes l’une de l’autre : autrement dit, deux méthodes sont en conflit si et seulement si les classes qui les introduisent sont en conflit.
Proposition 3.1 (Coloration de méthodes parfaite) L’existence d’une coloration parfaite des classes en-traîne celle d’une coloration parfaite des méthodes (resp. des attributs).
La réciproque n’est vraie que si chaque classe introduit au moins une méthode (resp. un attribut).
Par conséquent, si l’existence d’une coloration parfaite dépend principalement de la structure de la hiérarchie, la répartition des méthodes dans les classes a aussi une influence. On peut affiner la proposition en remarquant que seules les classes qui introduisent des méthodes ou des attributs sont à considérer : Proposition 3.2 (Coloration de méthodes parfaite) Il existe une coloration parfaite de méthodes si et seulement si il existe une coloration parfaite de classes sur la restriction de la hiérarchie aux classes qui introduisent une méthode.
Lorsqu’il existe une coloration parfaite des classes, le calcul d’une coloration parfaite de méthodes ou d’attributs est simple : dans chaque classe, les méthodes (resp. attributs) sont placées dans l’ordre des couleurs des classes qui les introduisent. Les classes de même signe n’étant pas en conflit, leurs méthodes
Coloration de méthodes ou d’attributs : résultats 30
de la couleur du trou : on obtient donc une coloration de méthodes correcte mais non optimale car les trous auraient pu être en partie bouchés, dans les sous-classes, au fur et à mesure de la raréfaction du nombre de classes en conflit.
En ce qui concerne l’implémentation, la coloration de méthodes est globalement simplifiée par le fait que toutes ses entrées sont de taille uniforme (des adresses) et que le typage statique rend inutile le test de débordement de table. Ce dernier point reste valable pour la coloration d’attributs ou pour l’implémentation des attributs par décalage dans la coloration de classe : dans les deux cas, l’implémentation non uniforme est une complication dont l’intérêt est réel, mais marginal.
3.2 Heuristiques
Une heuristique générale, qui assure une coloration parfaite lorsque la coloration de classes est parfaite tout en restant simple, consiste à colorer les méthodes et attributs dans l’ordre de la coloration des classes d’une heuristique de coloration de classes. Lorsque la coloration est parfaite, pour une classe qui introduit kméthodes (resp. attributs), les couleurs libres minimales sont leskpremières couleurs non allouées.
Lorsque la coloration de méthodes ou d’attributs n’est pas parfaite, la notion de couleurs libres mini-males est plus délicate à définir. On peut les définir comme :
– l’ensemble des couleurs libres à l’intérieur des couleurs héritées, s’il y en a assez,
– complété par un ensemble dek0 couleurs extérieures aux couleurs héritées et le plus contiguës pos-sibles.
Dans le cas unidirectionnel, il suffit de prendre lesk0premières couleurs libres.
Le problème se complique dans le cas bidirectionnel. Le deuxième ensemble peut alors se calculer de la façon suivante : on calcule d’abord le nombre de trous que causerait l’allocation desk0couleurs nécessaires dans les premières couleurs libres positives ou négatives. Si le nombre de trous est inférieur d’un côté, on commence par y allouer les couleurs jusqu’à la première couleur interdite et on met à jour le nombre de trous du côté opposé. On continue tant que toutes les couleurs nécessaires n’ont pas été allouées.
Cette approche permet d’adapter facilement les heuristiques de coloration de classes. Son avantage principal est de dépendre essentiellement du nombre de classes, et non pas du nombre de méthodes ou d’attributs : le gain en temps est considérable.
Elle a pourtant plusieurs défauts, qu’il faudrait chercher à corriger si l’on vise à de bonnes heuristiques : – dans le cas bidirectionnel, l’heuristique n’assure pas toujours une coloration parfaite lorsqu’elle existe : en effet, le graphe de conflit peut ne pas être biparti alors que sa restriction aux classes qui introduisent des méthodes (ou des attributs) l’est. Les heuristiques *2** et *3** basées sur une bipartition préalable ont été adaptées pour s’appliquer à la bonne restriction : elles assurent donc bien une coloration parfaite lorsqu’elle existe, mais elles donnent des résultats médiocres si la colo-ration n’est pas parfaite. Quant à l’heuristique *1** il faudrait l’adapter pour garantir une colocolo-ration parfaite.
– dans le schéma général choix d’un maximal, choix d’une couleur, la première étape ne dépend pas des nombres d’attributs et de méthodes ;
– la randomisation est difficile : pour le choix du maximal, il n’y a pas de problème, mais le choix de la couleur devient ensembliste et le tirage au sort d’un ensemble de couleurs libres minimales devient plus ardu et coûteux.
3.3 Généralisations
Deux généralisations nécessitent une adaptation du calcul des couleurs libres minimales.
3.3.1 Attributs d’implémentation non uniforme
Coloration de méthodes ou d’attributs : résultats 31
le cas pour les attributs, dont la table contient, soit l’adresse, s’il s’agit d’un objet construit, soit une va-leur immédiate (par exemple entier). Lorsque le type de l’attribut n’est pas polymorphe (type primitif par exemple) et qu’il s’implémente sur un nombre constant de mots (double précision, nombre complexes, etc.), il est préférable de l’implémenter directement dans l’objet plutôt que d’ajouter une indirection. C’est ce que permet de faire le mot-cléexpandedd’EIFFELpar exemple.
Dans ce cas, la définition des couleurs libres minimales donnée ci-dessus doit être adaptée pour allouer le nombre suffisant de mots, et de couleurs. Il ne suffit pas de compter les mots et non pas les attributs et d’affecter ensuite les couleurs aux attributs car le résultat ne serait pas toujours correct : il faut en effet que chaque attribut ait des couleurs contiguës.
Le problème est manifestement non trivial, et vraisemblablement NP-difficile (par réduction au pro-blème de la bipartition). En revanche, la bidirectionnalité ne le complique en rien, toute solution dans le cas unidrectionnel servant de base à une solution dans le cadre bidriectionnel, de la même façon que précédemment.
3.3.2 Coloration simultanée des méthodes et des classes
Il est vraisemblable que la meilleur utilisation de la coloration consiste à colorer simultanément les méthodes et les classes. Si l’on compte la classe pour une méthode, il s’agit encore d’un cas particulier de la coloration de méthodes, avec le même graphe de conflit que pour la coloration de classes. Mais, dans cette coloration, une classe a besoin de moins de place qu’une méthode : s’il faut une adresse pour cette dérnière, l’identifiant de classe se contente d’un petit entier.
Allouer 2 fois plus de place aux méthodes qu’aux classes, ressemble à un cas particulier du problème précédent. Cependant, l’architecture des processeurs fait préférer généralement d’utiliser des adresses ali-gnées sur les mots, ce qui imposerait d’imposer la parité des couleurs pour les méthodes, mais pas pour les classes. De fait, l’algorithme de calcul des couleurs libres minimales s’adapterait simplement, aussi bien dans le cas bidirectionnel que dans le cas unidirectionnel : chaque classe nécessite2k+ 1couleurs, soitk blocs de 2 couleurs alignées, allouées d’abord, et 1 couleur non alignée, allouée ensuite.
3.4 Statistiques
Les statistiques de coloration de méthodes et d’attributs sont présentées dans différentes configuration : – coloration de la hiérarchie totale ou restriction aux feuilles pour simuler la présence de classes abs-traites ; en revanche, la coloration réduite au cœur n’est pas présentée car elle n’a pas d’intérêt ici ; – coloration d’attributs, de méthodes ou de classes et méthodes simultanément (dans ce dernier cas, en
allouant le même nombre de couleurs aux méthodes et aux classes) ;
– les statistiques ont été effectuées sur quelques heuristiques seulement, parmi les meilleures (0164 et 0167) ;
– la bipartition préalable s’applique mal car il peut être contre-productif d’allouer toutes les couleurs du même côté.
3.4.1 Statistiques réduites aux feuilles
Pour simuler la restriction de la coloration aux classes concrètes — par opposition aux classes abstraites qui ne sont pas instanciables — nous proposons aussi les statistiques de coloration réduites aux feuilles des hiérarchies. La restriction aux classes abstraites est aussi valable pour la coloration de classe dans la mesure où le test de sous-typage n’est a priori nécessaire que pour le downcast : le type cible est quelconque mais le type source est toujours la classe d’une instance, donc une classe non abstraite.
1eroctobre 2003