Ciao a tutti,
vorrei esporvi l'idea che mi sono fatto in relazione alla gestione della memoria da parte di un SO e quelle che invece sono le tematiche relative all'organizzazione della memoria destinata ad un programma da parte del programma stesso. Faccio questo per aver conferme, smentite e precisazioni
Premessa: per quanto riguarda un SO io non sarò preciso nel dettaglio, il mio scopo non è quello ma far collimare le questioni lato SO con quelle lato programma in esecuzione.
Grosso modo un SO dispone di una memoria principale (la RAM) e una memoria di massa. La memoria in cui viene caricato ciò che si sta eseguendo è la RAM ma per evitare che ogni programma abbia pesantemente a che fare con le limitazioni di spazio in RAM non si carica l'intero eseguibile (almeno non necessariamente) ma soltanto porzioni di questo, lasciando la sua copia completa in un'area della memoria di massa (da ora dirò HD) dedicata a questo meccanismo. Così facendo ogni programma è come se avesse a disposizione una memoria (virtuale) pari al numero di celle indirizzabili, che nel caso di un sistema a 32 bit sono 4 GB. Ogni volta che l'esecuzione del programma in questione va a puntare a indirizzi (relativi al programma stesso) non ancora caricati in RAM, avviene un page fault: in pratica il SO deve trovar spazio in RAM (memoria fisica) per caricare da HD le nuove parti di eseguibile chiamate in causa dall'esecuzione. Il meccanismo ovviamente è dispendioso e SO gestirà queste situazioni secondo algoritmi che minimizzino i page fault etc (non mi interessa ora entrar troppo nello specifico).
Abbiamo quindi un eseguibile contenente (non so bene come organizzati ma anche qui per ora non andrei troppo in dettaglio per non perdere di vista l'obiettivo del mio discorso) le istruzioni e le variabili per un totale di N comandi macchina equivalenti a N celle di memoria. Tale eseguibile nelle sue istruzioni punta a indirizzi di celle relative a se stesso immaginando che la prima cella sia all'indirizzo 0 della memoria. Ha quindi un suo mondo a se stante e quando viene spezzato in parti e caricato in RAM dall'SO la rivalutazione degli indirizzi delle celle a cui puntano le istruzioni dell'eseguibile etc. son questioni del tutto trasparenti al codice eseguibile del programma in esecuzione.
Dal punto di vista dell'eseguibile quindi vi è del codice, delle variabili e della memoria dove sono contenuti e organizzati. Qui subentra per me la visione del programma e le tematiche relative a stack, heap etc. Sono questioni che riguardano il mondo del programma in esecuzione e le questioni relative all'SO e alla gestione della memoria virtuale/fisica restano ad un livello sottostante del tutto trasparente al programma. Corretto?
Non riesco però a capire se devo quindi immaginare l'eseguibile come codice+variabili in una memoria dedicata che al suo interno è organizzata in stack, heap etc...o se ciò che creo in runtime con new (quindi heap) sia qualcosa che va al di là della gestione interna dell'eseguibile e viene allocata in ram in tempo reale dal so. Inoltre non capisco come e se gli oggetti creati in runtime (quindi non compresi nel codice eseguibile che si lancia) siano soggetti al meccanismo di paginazione etc: restano sempre in ram o rientrano come tutto il resto nel meccanismo che a livello sottostante esegue l'SO?
Resta però il fatto che io potrei da programma voler controllare quanta memoria virtuale e/o fisica sto occupando di modo eventualmente da "gestirla" distruggendo istanze di oggetti etc. Ciò che però mi interessa gestire, cioè che ha un valore dal punto di vista del programmatore e del programma, è la memoria fisica occupata oppure quella virtuale (che dovrebbe essere >= di quella fisica, a seconda se in ram si carica tutto o solo una parte dell'eseguibile) ? La creazione di istanze in runtime fa aumentare la memoria fisica sempre o potrebbero in intervalli temporali finire su memoria di massa e quindi non incidere in ram?
Spero di non aver fatto troppa confusione, grazie a tutti