Systeme d'exploitation
Fermé
omar_rou
Messages postés
17
Date d'inscription
mardi 4 janvier 2011
Statut
Membre
Dernière intervention
20 mars 2012
-
24 févr. 2011 à 18:52
mamiemando Messages postés 33401 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 28 novembre 2024 - 3 mars 2011 à 21:55
mamiemando Messages postés 33401 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 28 novembre 2024 - 3 mars 2011 à 21:55
A voir également:
- Systeme d'exploitation
- Restauration systeme - Guide
- Comment connaitre son système d'exploitation - Guide
- Comment refaire le système d'un ordinateur - Guide
- Cloner disque systeme - Guide
- Système d’exploitation 32 bits, processeur x64 - Forum Matériel & Système
3 réponses
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
24 févr. 2011 à 20:50
24 févr. 2011 à 20:50
Quel rapport avec blueJ et un système d'exploitation ?
Quelle est ta question ?
Quelle est ta question ?
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
27 févr. 2011 à 05:46
27 févr. 2011 à 05:46
Bah je ne vois pas trop le rapport avec java mais bon... Dans l'idée :
Un garbage collector repère les blocs mémoires alloués mais qui ne sont plus référencés dans le programme. Une stratégie consiste à maintenir un compteur de référence sur le bloc mémoire. À chaque fois que cet espace est référencé, on incrémente le compteur. Et on le décrémente à chaque fois qu'une référence est détruite.
S'il tombe à zéro, le garbage collector part du principe que l'espace mémoire en question n'est plus utilisé puisqu'il n'y a plus de variable qui permet d'y accéder.
Sans garbage collector ces quelques lignes engendre une fuite mémoire (ce serait le cas en c++ par exemple). C'est la raison pour laquelle en C et en C++ on utilise des outils comme valgrind alors que ces considérations passent au dessus de la tête de la plupart des développeurs c# ou java.
Une allocation mémoire cherche dans un espace un bloc de mémoire de la taille demandé. Si aucun endroit n'est trouvé (mémoire fragmentée ou saturée), alors elle renvoit traditionnellement une adresse nulle (cf malloc). Dans ce cas comme l'espace n'a pas été alloué, il ne doit pas être libéré.
À part ça je ne vois pas trop quoi te dire de plus car je n'ai pas vraiment compris ce qu'on te demande de faire. Recoder un pseudo langage qui maintient dans son runtime tous les aspects mémoires ? Mystère.
Bonne chance
Un garbage collector repère les blocs mémoires alloués mais qui ne sont plus référencés dans le programme. Une stratégie consiste à maintenir un compteur de référence sur le bloc mémoire. À chaque fois que cet espace est référencé, on incrémente le compteur. Et on le décrémente à chaque fois qu'une référence est détruite.
S'il tombe à zéro, le garbage collector part du principe que l'espace mémoire en question n'est plus utilisé puisqu'il n'y a plus de variable qui permet d'y accéder.
Personne p = new Personne("Toto"); // on crée un espace référencé par p Personne q = p; // il est maintenant référencé 2 fois Personne p = null; // il est maintenant référencé 1 fois Personne q = null; // il est maintenant référencé 0 fois => garbage collector
Sans garbage collector ces quelques lignes engendre une fuite mémoire (ce serait le cas en c++ par exemple). C'est la raison pour laquelle en C et en C++ on utilise des outils comme valgrind alors que ces considérations passent au dessus de la tête de la plupart des développeurs c# ou java.
Une allocation mémoire cherche dans un espace un bloc de mémoire de la taille demandé. Si aucun endroit n'est trouvé (mémoire fragmentée ou saturée), alors elle renvoit traditionnellement une adresse nulle (cf malloc). Dans ce cas comme l'espace n'a pas été alloué, il ne doit pas être libéré.
#include <stdlib.h> #include <stdio.h> int main(){ void *p = malloc(1000); // alloue un bloc de 1000 octets if(!p){ fprintf(stderr, "allocation échouée"); // On quitte le programme sans libérer p. // Par contre il faut libérer les autres choses qui ont été allouées // avec succès, sinon on a une fuite mémoire (memory leak). return 1; } // p a été alloué avec succès, je peux l'utiliser. //... // Le programme se termine, qui dit malloc réussi dit free ! free(p); // note que la taille du bloc n'apparaît pas // On quitte le programme return 0; }
À part ça je ne vois pas trop quoi te dire de plus car je n'ai pas vraiment compris ce qu'on te demande de faire. Recoder un pseudo langage qui maintient dans son runtime tous les aspects mémoires ? Mystère.
Bonne chance
foobar47
Messages postés
13536
Date d'inscription
jeudi 9 janvier 2003
Statut
Contributeur
Dernière intervention
16 mai 2014
532
3 mars 2011 à 15:00
3 mars 2011 à 15:00
Ca se voit que c'est les vacances...
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
3 mars 2011 à 21:55
3 mars 2011 à 21:55
?
24 févr. 2011 à 22:09
24 févr. 2011 à 22:43
25 févr. 2011 à 16:06
25 févr. 2011 à 18:25
Option : le simulateur continue de générer des couples, qui sont placés dans une queue.
La taille de la mémoire vive de l'ordinateur est supposée être 1000 Mo. dont 256 Mo sont occupés par le SE. La « taille » des programmes ne dépassera pas 500 Mo et leur « durée d'exécution » sera comprise entre 1 et 10 secondes.
Le simulateur produira en sortie une représentation textuelle du fonctionnement.
Option : le simulateur produit également une sortie graphique, montrant le chargement, la libération et la collecte des déchets.
25 févr. 2011 à 18:25