Je voudrais v=E9rifier si la m=E9moire de mon programme =E9crit en C,
compil=E9 sous linux, et bien lib=E9r=E9e.
J'ai essay=E9 avec la command 'top' qui donne la taille en m=E9moire
VIRT, RES et SHR. Au fur =E0 =E0 mesure que des dossiers sont ouverts,
la taille de VIRT et RES augmente, mais au fur et =E0 mesure que les
dossiers sont ferm=E9s, la taille de RES reste =E0 la m=EAme valeur et ne
revient pas =E0 la taille initiale.
Ca fait la m=EAme chose avec l'=E9diteur 'vim', dont je suppose qu'il
fonctionne correctement, et ou la taille augmente au fur et =E0 mesure
de l'ouverture de fichiers, mais reste constante au fur et mesure de la
fermeture des fichiers.
Aussi, je me demande si cette m=E9thode est valable, sinon existe-il
d'autres m=E9thodes pour v=E9rifier la lib=E9ration de la m=E9moire?
Je pense que MVS (z/OS, *l'autre* OS des gros IBM) est un système d'exploitation « classique », avec mémoire virtuelle matérielle.
Vous pouvez m'expliquer comment on fait de la mémoire virtuelle sans interruption materielle ?
-- NOUVELLE proposition pour USENET-FR : AAD1 : news: BILAN1 : news:45bb70d0$0$2381$
Antoine Leca
Harpo écrivit dans news:45c329ec$0$458$:
Antoine Leca wrote:
Je pense que MVS (z/OS, *l'autre* OS des gros IBM) est un système d'exploitation « classique », avec mémoire virtuelle matérielle.
Vous pouvez m'expliquer comment on fait de la mémoire virtuelle sans interruption materielle ?
Bin c'est justement la solution Windows, « le multitâche coopératif ». D'une part, pour pallier le fait que la base de temps pouvait être « volée », ou (selon son point de vue) que les applications s'attendaient à ce que tout le temps disponible leur soit attribué, la norme de programmation explicitait que les applications devait « rendre la main » dès que possible et le plus souvent possible (Yield()). Ça, c'est le coopératif.
Mais dans les normes de programamtion, il y a(vait) aussi des normes de gestion de mémoire, et en particulier les applications devaient utiliser un mécanisme de verrouillage explicite. Évidemment, quand les blocs alloués n'était pas verrouillés, ou quand l'application est complètement virée en mémoire secondaire, le système, quand il a la main (cf.supra) est libre de faire valser les blocs à sa guise, par exemple pour charger une autre application. Et hop, on a un système de mémoire virtuelle (possible d'avoir plus de mémoire utilisée à un moment donnéee qu'il n'y a de mémoire physiquemnt installée).
Antoine
Harpo écrivit dans news:45c329ec$0$458$426a74cc@news.free.fr:
Antoine Leca wrote:
Je pense que MVS (z/OS, *l'autre* OS des gros IBM) est un système
d'exploitation « classique », avec mémoire virtuelle matérielle.
Vous pouvez m'expliquer comment on fait de la mémoire virtuelle sans
interruption materielle ?
Bin c'est justement la solution Windows, « le multitâche coopératif ».
D'une part, pour pallier le fait que la base de temps pouvait être «
volée », ou (selon son point de vue) que les applications s'attendaient à ce
que tout le temps disponible leur soit attribué, la norme de programmation
explicitait que les applications devait « rendre la main » dès que possible
et le plus souvent possible (Yield()). Ça, c'est le coopératif.
Mais dans les normes de programamtion, il y a(vait) aussi des normes de
gestion de mémoire, et en particulier les applications devaient utiliser un
mécanisme de verrouillage explicite. Évidemment, quand les blocs alloués
n'était pas verrouillés, ou quand l'application est complètement virée en
mémoire secondaire, le système, quand il a la main (cf.supra) est libre de
faire valser les blocs à sa guise, par exemple pour charger une autre
application. Et hop, on a un système de mémoire virtuelle (possible d'avoir
plus de mémoire utilisée à un moment donnéee qu'il n'y a de mémoire
physiquemnt installée).
Je pense que MVS (z/OS, *l'autre* OS des gros IBM) est un système d'exploitation « classique », avec mémoire virtuelle matérielle.
Vous pouvez m'expliquer comment on fait de la mémoire virtuelle sans interruption materielle ?
Bin c'est justement la solution Windows, « le multitâche coopératif ». D'une part, pour pallier le fait que la base de temps pouvait être « volée », ou (selon son point de vue) que les applications s'attendaient à ce que tout le temps disponible leur soit attribué, la norme de programmation explicitait que les applications devait « rendre la main » dès que possible et le plus souvent possible (Yield()). Ça, c'est le coopératif.
Mais dans les normes de programamtion, il y a(vait) aussi des normes de gestion de mémoire, et en particulier les applications devaient utiliser un mécanisme de verrouillage explicite. Évidemment, quand les blocs alloués n'était pas verrouillés, ou quand l'application est complètement virée en mémoire secondaire, le système, quand il a la main (cf.supra) est libre de faire valser les blocs à sa guise, par exemple pour charger une autre application. Et hop, on a un système de mémoire virtuelle (possible d'avoir plus de mémoire utilisée à un moment donnéee qu'il n'y a de mémoire physiquemnt installée).
Antoine
Antoine Leca
Harpo écrivit dans news:45c75b61$0$4942$:
Mais dans les normes de programamtion, il y a(vait) aussi des normes de gestion de mémoire, et en particulier les applications devaient utiliser un mécanisme de verrouillage explicite. Évidemment, quand les blocs alloués n'était pas verrouillés, ou quand l'application est complètement virée en mémoire secondaire, le système, quand il a la main (cf.supra) est libre de faire valser les blocs à sa guise, par exemple pour charger une autre application.
C'était des blocs de données pouvant contenir des adresses ?
Oui.
Il utilisait une indirection systématique pour l'adressage ?
Pas vraiment. Mais un pointeur vers un bloc non verrouillé était « automatiquement » invalide (en C, on dit « le comportement est indéterminé »... et de fait , il est extrêment difficile de déterminer le comportement après une erreur de programmation de ce genre !)
Sinon, le système (dit mode réel) jouait avec les pointeurs (suivant qu'ils étaient pairs ou impairs, par exemple) pour repérer les pointeurs vers des zones valides ou pas, et les modifiaient à la volée. Surtout avec la pile...
il devait charger les blocs au même endroit physique ?
Même pas ! Remarque qu'à l'époque Windows était renommé pour sa lenteur, et il y avait des raisons à cela !
En mode protégé (dit "standard", apparu avec Windows 3.0), MS a changé de jeu et utilisé la mémoire virtuelle segmentée du processeur 80286 ; à partir de là, c'est la MMU qui faisait coller l'adresse segmentée (constante) avec l'adresse physique (variable). Les performances ont progressée, mais surtout la fiabilité du bouzin a grimpé en flèche !
faire de la relocation d'adresses ?
Et oui, et à la mimine encore !
J'ai entendu parler de choses comme ça quand j'ai commencé il y a, disons 3O ans par coqueterie, c'était déjà ringard. Ils appelaient cela 'overlay', c'était des morceaux de programmes que c'était au programmeur d'application de faire gaffe ne pas en vouloir 2 différents au même endroit au même moment, une horreur, ce n'est typiquement pas son boulot, il doit s'occuper de ses données, de ses algorithmes etc. pas de ces misères.
Exact. Avec Windows, c'était pareil sous le capot (overlays compris), mais la partie jolie c'est que le programmeur applicatif n'avait effectivement pas à s'occuper de tout cela... sauf que:
- les programmeurs système mettaient des années à faire marcher convenablement leur bouzin, entre temps le hard avait progresser au point que les applis devenaient dépassées; le comble dans ce domaine c'était OS/2, quand c'est sorti en 1987-88 il fallait un 386 pour faire tourner l'OS convenablement mais le système ne savait pas sauvegarder le contexte 32 bits, donc deux tâches en 32 bits et tu faisais tout exploser...
- au moindre souci il fallait revenir au niveau en dessous, c'est-à-dire se pallucher la compréhesion de tout le biniou que l'on essayait justement de cacher !
- les contraintes au niveau de l'API ne plaisaient ni aux programmeurs (ah ! les fameux 64 K), ni aux compilateurs genre C (qui, avec leurs ascendance Unix s'accommodaient _très mal_ des joies de la segmentation ou du modèle évenementiel).
Bref, ce n'était pas encore la panacée.
Antoine
Harpo écrivit dans news:45c75b61$0$4942$426a74cc@news.free.fr:
Mais dans les normes de programamtion, il y a(vait) aussi des normes
de gestion de mémoire, et en particulier les applications devaient
utiliser un mécanisme de verrouillage explicite. Évidemment, quand
les blocs alloués n'était pas verrouillés, ou quand l'application est
complètement virée en mémoire secondaire, le système, quand il a la
main (cf.supra) est libre de faire valser les blocs à sa guise, par
exemple pour charger une autre application.
C'était des blocs de données pouvant contenir des adresses ?
Oui.
Il utilisait une indirection systématique pour l'adressage ?
Pas vraiment. Mais un pointeur vers un bloc non verrouillé était «
automatiquement » invalide (en C, on dit « le comportement est
indéterminé »... et de fait , il est extrêment difficile de déterminer le
comportement après une erreur de programmation de ce genre !)
Sinon, le système (dit mode réel) jouait avec les pointeurs (suivant qu'ils
étaient pairs ou impairs, par exemple) pour repérer les pointeurs vers des
zones valides ou pas, et les modifiaient à la volée. Surtout avec la pile...
il devait charger les blocs au même endroit physique ?
Même pas ! Remarque qu'à l'époque Windows était renommé pour sa lenteur, et
il y avait des raisons à cela !
En mode protégé (dit "standard", apparu avec Windows 3.0), MS a changé de
jeu et utilisé la mémoire virtuelle segmentée du processeur 80286 ; à partir
de là, c'est la MMU qui faisait coller l'adresse segmentée (constante) avec
l'adresse physique (variable). Les performances ont progressée, mais surtout
la fiabilité du bouzin a grimpé en flèche !
faire de la relocation d'adresses ?
Et oui, et à la mimine encore !
J'ai entendu parler de choses comme ça quand j'ai commencé il y a,
disons 3O ans par coqueterie, c'était déjà ringard. Ils appelaient
cela 'overlay', c'était des morceaux de programmes que c'était au
programmeur d'application de faire gaffe ne pas en vouloir 2
différents au même endroit au même moment, une horreur, ce n'est
typiquement pas son boulot, il doit s'occuper de ses données, de ses
algorithmes etc. pas de ces misères.
Exact. Avec Windows, c'était pareil sous le capot (overlays compris), mais
la partie jolie c'est que le programmeur applicatif n'avait effectivement
pas à s'occuper de tout cela... sauf que:
- les programmeurs système mettaient des années à faire marcher
convenablement leur bouzin, entre temps le hard avait progresser au point
que les applis devenaient dépassées; le comble dans ce domaine c'était OS/2,
quand c'est sorti en 1987-88 il fallait un 386 pour faire tourner l'OS
convenablement mais le système ne savait pas sauvegarder le contexte 32
bits, donc deux tâches en 32 bits et tu faisais tout exploser...
- au moindre souci il fallait revenir au niveau en dessous, c'est-à-dire se
pallucher la compréhesion de tout le biniou que l'on essayait justement de
cacher !
- les contraintes au niveau de l'API ne plaisaient ni aux programmeurs (ah
! les fameux 64 K), ni aux compilateurs genre C (qui, avec leurs ascendance
Unix s'accommodaient _très mal_ des joies de la segmentation ou du modèle
évenementiel).
Mais dans les normes de programamtion, il y a(vait) aussi des normes de gestion de mémoire, et en particulier les applications devaient utiliser un mécanisme de verrouillage explicite. Évidemment, quand les blocs alloués n'était pas verrouillés, ou quand l'application est complètement virée en mémoire secondaire, le système, quand il a la main (cf.supra) est libre de faire valser les blocs à sa guise, par exemple pour charger une autre application.
C'était des blocs de données pouvant contenir des adresses ?
Oui.
Il utilisait une indirection systématique pour l'adressage ?
Pas vraiment. Mais un pointeur vers un bloc non verrouillé était « automatiquement » invalide (en C, on dit « le comportement est indéterminé »... et de fait , il est extrêment difficile de déterminer le comportement après une erreur de programmation de ce genre !)
Sinon, le système (dit mode réel) jouait avec les pointeurs (suivant qu'ils étaient pairs ou impairs, par exemple) pour repérer les pointeurs vers des zones valides ou pas, et les modifiaient à la volée. Surtout avec la pile...
il devait charger les blocs au même endroit physique ?
Même pas ! Remarque qu'à l'époque Windows était renommé pour sa lenteur, et il y avait des raisons à cela !
En mode protégé (dit "standard", apparu avec Windows 3.0), MS a changé de jeu et utilisé la mémoire virtuelle segmentée du processeur 80286 ; à partir de là, c'est la MMU qui faisait coller l'adresse segmentée (constante) avec l'adresse physique (variable). Les performances ont progressée, mais surtout la fiabilité du bouzin a grimpé en flèche !
faire de la relocation d'adresses ?
Et oui, et à la mimine encore !
J'ai entendu parler de choses comme ça quand j'ai commencé il y a, disons 3O ans par coqueterie, c'était déjà ringard. Ils appelaient cela 'overlay', c'était des morceaux de programmes que c'était au programmeur d'application de faire gaffe ne pas en vouloir 2 différents au même endroit au même moment, une horreur, ce n'est typiquement pas son boulot, il doit s'occuper de ses données, de ses algorithmes etc. pas de ces misères.
Exact. Avec Windows, c'était pareil sous le capot (overlays compris), mais la partie jolie c'est que le programmeur applicatif n'avait effectivement pas à s'occuper de tout cela... sauf que:
- les programmeurs système mettaient des années à faire marcher convenablement leur bouzin, entre temps le hard avait progresser au point que les applis devenaient dépassées; le comble dans ce domaine c'était OS/2, quand c'est sorti en 1987-88 il fallait un 386 pour faire tourner l'OS convenablement mais le système ne savait pas sauvegarder le contexte 32 bits, donc deux tâches en 32 bits et tu faisais tout exploser...
- au moindre souci il fallait revenir au niveau en dessous, c'est-à-dire se pallucher la compréhesion de tout le biniou que l'on essayait justement de cacher !
- les contraintes au niveau de l'API ne plaisaient ni aux programmeurs (ah ! les fameux 64 K), ni aux compilateurs genre C (qui, avec leurs ascendance Unix s'accommodaient _très mal_ des joies de la segmentation ou du modèle évenementiel).
