De nouveaux attributs pour les entitŽs

Sous-section Pn

Figure 5.8. Un format objet pour une application parall•le

Ce format pourra aussi bien •tre dŽrivŽ du format TCOFF existant dÕINMOS [SDPW91] sÕil permet facilement le rajout dÕextensions, ou de tout autre format (stan-dard COFF par exemple) susceptible de rŽpondre ˆ nos besoins.

LÕintŽr•t de cette reprŽsentation rŽside dans sa grande souplesse : en effet, il permet de rester relativement compatible avec les formats objets existants (gr‰ce ˆ lÕorganisation en sections, le chargeur peut par exemple compl•tement ignorer les informations de re-location, si le syst•me nÕest pas capable de les utiliser) et il autorise les extensions sans aucune modification du format existant (il suffit de rajouter une section avec une ent•te spŽcifique).

5.2.3.2 De nouveaux attributs pour les entitŽs

Dans lÕent•te de chaque section, il existe un champ qui dŽcrit les attributs dÕune entitŽ. Ces attributs indiquent au syst•me comment lÕentitŽ doit •tre chargŽe, placŽe, gŽrŽe, etc. Nous connaissons dŽjˆ les attributs qui dŽcrivent la visibilitŽ dÕune entitŽ (privŽe ou publique) et sa rŽfŽrence (statique ou global, adhŽrent), Cf. Chapitre 4,.2.2 VisibilitŽ et

4.2.3 RŽfŽrence pour plus dÕinformations. Ainsi, les attributs statique, global et public

dŽtermine la structure de lÕidentificateur de lÕentitŽ.

Mais, nous avons aussi introduit dÕautres concepts comme le cluster mŽmoire, et le cluster de contr™le. En particulier, nous avons vu quÕaller chercher une entitŽ sur disque

Chapitre 5 : Gestion des entitŽs dans ParObj

pouvait •tre une opŽration cožteuse en temps, surtout si la machine est chargŽe. Aussi, par exemple, pouvoir spŽcifier que le programme doit •tre compl•tement placŽ en mŽ-moire avant sont exŽcution, peut •tre une fonctionnalitŽ intŽressante. De m•me, une Pt‰che peut avoir envie de placer certaines de ces entitŽs sur le processeur de contr™le (qui, nous le verrons bient™t conserve la localisation de toute les entitŽs globales de la Pt‰che), afin par exemple, de faciliter des communications ou de la migration dÕentitŽs avec dÕautres Pt‰ches.

Ces attributs sont stockŽs parmi les nombreux indicateurs que nous trouvons dans lÕen-t•te de chaque section dŽcrivant une entitŽ. Chaque attribut est codŽ sur un bit, un 1 in-diquant sa prŽsence et un 0 son absence. La structure du champ attribut est la suivante :

Reserved aPrivate/aPublic (0/1) aStatic/aGlobal (0/1) aSticky aReadOnly aPreload aControl aSharable aDisposable aStuckInMem aModified

DŽtaillons maintenant un peu plus la signification de ces diffŽrents attributs. Les attri-buts en italique dŽcrivent la visibilitŽ et la rŽfŽrence dÕune entitŽ :

¥ aPrivate. Pour toute entitŽ qui nÕest visible quÕˆ lÕintŽrieur dÕune Pt‰che. Une

entitŽ qui nÕest pas privŽe est publique (aPublic).

¥ aStatic. Pour toute entitŽ qui nÕest visible que par les entitŽs situŽes sur le m•me processeur et ˆ condition que la liaison entre ces entitŽs soit connue ˆ la compilation. Une entitŽ qui nÕest pas statique est globale (aGlobal).

¥ aSticky. Pour tout entitŽ qui ne doit pas •tre migrŽe (entitŽ adhŽrente).

¥ aReadOnly. Pour toute entitŽ dont lÕacc•s est limitŽ ˆ la lecture (i.e. lÕŽtat de lÕobjet ne peut pas •tre modifiŽ). CÕest lÕŽquivalent de lÕattribut ÒimmuableÓ des objets dans Emerald [BHLC87].

Les attributs en gras ont un rapport avec la phase de chargement :

¥ aPreload. Pour toute entitŽ qui doit •tre chargŽe en mŽmoire avant lÕexŽcution de la Pt‰che, m•me si lÕentitŽ nÕest pas immŽdiatement utilisŽe. Ce champ est par exemple tr•s utile lorsque nous voulons faire des tests de performances pures, et que nous ne voulons pas prendre en compte le surcožt introduit par le transfert du disque vers la mŽmoire dÕune entitŽ crŽŽe dynamiquement. A lÕopposŽ, si lÕutili-sateur sait que certaines entitŽs de son programme ne seront utilisŽes que dans de

Chapitre 5 : Gestion des entitŽs dans ParObj

tr•s rares occasions, il prŽfŽrera ne pas les charger ˆ lÕavance, se rŽservant ainsi de la place pour les autres entitŽs et Žvitant donc dÕŽventuels probl•mes de manque de mŽmoire.

Cet attribut est tr•s utilisŽ dans le syst•me dÕexploitation du Macintosh (Cf. [Apple88], Resource Manager pour plus dÕinformations) lors du chargement des ressources dÕune application.

LÕutilisateur dispose aussi dÕun champ aPreload au niveau de la Pt‰che. Si ce-lui-ci est ˆ un, alors toute lÕapplication sera chargŽe en mŽmoire, et quelque soit la valeur de lÕattribut aPreload de chaque entitŽ. Si au contraire il est ˆ zŽro, alors chaque attribut sera pris en compte.

Ceci permet de rŽaliser ce que les concepteurs du SDO PEACE appellent Òchargement incrŽmentalÓ ou chargement ˆ la demande. Par exemple, Un biblio-th•que mathŽmatique pourra avoir lÕattribut aPreload de sa Pt‰che ˆ zŽro. De cette mani•re, tant quÕelle nÕest pas utilisŽe, seul le processeur de contr™le de cette Pt‰che est initialisŽ. LorquÕune Pt‰che utilisateur fait appel ˆ la biblioth•que, la t‰che de contr™le du processeur de contr™le allouera alors un ou plusieurs proces-seurs et chargera tout ou une partie de la biblioth•que.

Note : Le champ aPreload dÕun attribut est ˆ 1 par dŽfaut.

¥ aControl. Pour toute entitŽ qui doit •tre placŽe sur le processeur de contr™le. Par exemple, toute t‰che qui communique avec une t‰che dÕune autre Pt‰che pourra •tre installŽe sur ce processeur, afin de rŽduire les cožts de communica-tions, Cf. ¤ sur la gestion des entitŽs. A priori, seuls des utilisateurs privilŽgiŽs au-ront le droit dÕutiliser cette fonctionnalitŽ (pour des raisons Žvidentes de protec-tion des acc•s entre Pt‰ches).

Enfin, les attributs restant servent pour la gestion mŽmoire de lÕentitŽ (les attributs aDisposable, aStuckInMem, et aModified) nÕayant un sens que lorque lÕentitŽ est effectivement prŽsente en mŽmoire :

¥ aSharable. Pour toute entitŽ qui peut •tre partageable. Par exemple, une entitŽ en lecture seule (aReadOnly) peut •tre partageable.

¥ aDisposable. Indique au syst•me que lÕentitŽ peut •tre dŽfinitivement retirŽe de la mŽmoire dans laquelle elle se trouve (par exemple ˆ la suite de la destruction de lÕentitŽ). Cependant, cette entitŽ nÕest rŽellement purgŽe de la mŽmoire que lorsque le gestionnaire de mŽmoire ˆ vraiment besoin de faire de la place.

Cet attribut permet parfois de rŽduire les acc•s disque. En effet, supposons quÕune t‰che charge en mŽmoire un objet en lecture seule, acc•de ˆ ses donnŽes puis le dŽtruise. Supposons maintenant, quÕune autre t‰che ait besoin elle aussi dÕutiliser cet objet. Alors, si lÕobjet a ŽtŽ irrŽmŽdiablement ŽliminŽ de la mŽmoire apr•s sa destruction, le syst•me devra de nouveau rechercher sur le disque lÕobjet

Chapitre 5 : Gestion des entitŽs dans ParObj

convoitŽ. Si au contraire, il rŽside encore en mŽmoire, lÕacc•s sera quasiment im-mŽdiat. ƒvidemment cela suppose quÕentre temps la mŽmoire nÕait pas ŽtŽ satu-rŽe.

¥ aStuckInMem. Pour toute entitŽ qui ne doit pas •tre vidŽe sur disque m•me si le gestionnaire de mŽmoire a besoin de faire de la place. Cet attribut est tr•s pratique pour Žviter de vider sur disque des entitŽs qui sont accŽdŽes tr•s frŽquemment, permettant dÕŽviter dÕincessant va et vient entre les diffŽrents niveaux de swap. Attention, lÕutilisation intempestive de cet attribut peut entra”ner de graves pro-bl•mes de fonctionnement dans la gestion de lÕapplication.

Note : lorsque lÕattribut aStuckInMem est ˆ un, lÕattribut aDisposable est compl•tement ignorŽ, et de plus, lÕentitŽ ne peut pas •tre migrŽe (i.e. elle se com-porte comme si son champ aSticky Žtait ˆ un).

¥ aModified. Est positionnŽ ˆ un lorsquÕune entitŽ a ŽtŽ modifiŽe. Seul le sys-t•me peut le mettre ˆ jour. Cet attribut est par exemple utilisŽ pour la gestion des objets persistants (si lÕobjet est dŽtruit, et quÕil a ŽtŽ modifiŽ, il faut rŽpercuter les changements sur le disque).

La zone Reserved comportent des champs utilisŽs par le syst•me et pour des exten-sions futuresÉ