# La gestión de la memoria [Abrir el PDF original](<../PDF/La gestión de la memoria.pdf>) > Conversión de texto página a página. La paginación permite cotejar este archivo con el PDF original. ## Página 1 La gestión de la memoria José Ramón Herrero Zaragoza Enric Morancho Llena Dolors Royo Vallés PID_00169383 ## Página 2 GNUFDL • PID_00169383 La gestión de la memoria © 2014, FUOC. Se garantiza permiso para copiar, distribuir y modificar este documento según los términos de la GNU Free Documentation License, Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Se dispone de una copia de la licencia en el apartado "GNU Free Documentation License" de este documento. ## Página 3 GNUFDL • PID_00169383 La gestión de la memoria Índice Introducción............................................................................................... 5 Objetivos....................................................................................................... 6 1. Espacios de direcciones..................................................................... 7 2. Un primer mecanismo de traducción dinámica........................ 9 2.1. Limitaciones de este sistema ....................................................... 11 3. Memoria virtual................................................................................. 13 3.1. Paginación ................................................................................... 13 3.1.1. Ubicación de las regiones de código, datos y pila dentro del espacio lógico .............................................. 15 3.1.2. ¿Evita la paginación las deficiencias del sistema presentado en el apartado 2? ........................................ 16 3.2. Paginación bajo demanda ........................................................... 17 4. Modificación dinámica del espacio lógico.................................. 21 4.1. Modificación dinámica del tamaño de la región de datos .......... 21 5. Errores de programación relacionados con el acceso a la memoria................................................................................................ 23 Resumen....................................................................................................... 26 Actividades.................................................................................................. 27 Ejercicios de autoevaluación.................................................................. 27 Solucionario................................................................................................ 29 Glosario........................................................................................................ 30 Bibliografía................................................................................................. 31 ## Página 4 ## Página 5 GNUFDL • PID_00169383 5 La gestión de la memoria Introducción En este módulo didáctico, presentamos los principios de la gestión de la me- moria principal, uno de los recursos más importantes de cualquier sistema operativo multiprogramado. La gestión￿de￿la￿memoria se encarga básicamen- te de asignar la memoria física del sistema computador, que es finita, a los procesos que la solicitan. Ningún programa se puede ejecutar si no se le ha asignado memoria principal para almacenar su código, sus datos y su pila de ejecución. Primero se introducen los espacios￿de￿direcciones, que son el lógico y el físi- co. Mientras que el espacio físico es único, cada proceso en ejecución tendrá asociado un espacio lógico; cada espacio lógico será independiente de los del resto de procesos. El sistema de gestión de la memoria esconderá el espacio físico a los usuarios y la visión que éstos tendrán de la memoria será el espa- cio lógico. Por lo tanto, será necesario un mecanismo que traduzca, de forma transparente para el usuario, los accesos al espacio lógico en accesos al espacio físico. La coexistencia de múltiples espacios de direcciones lógicos que pertenecen a diferentes procesos residentes en la memoria principal introduce la necesidad de proteger los espacios de direcciones. En un entorno multiprogramado, el gestor de la memoria tendría que disponer de mecanismos￿de￿protección de￿la￿memoria, es decir, tendría que garantizar que un proceso no pudiera acceder a la memoria física asignada a otro proceso o al sistema operativo. También es deseable que, si los procesos lo autorizan, acepte compartir￿la memoria y permita, así, espacios comunes para los procesos interesados. Presentamos la implementación de un gestor de memoria sencillo que, con la ayuda del hardware, cumple la mayoría de los requerimientos indicados. Una vez analizadas sus limitaciones, describimos el gestor de memoria virtual. Este último sistema será capaz de independizar los procesos de la cantidad de memoria física instalada en la máquina, con lo cual permitirá ejecutar procesos que no caben en la memoria física. Finalmente, reflexionamos sobre las posibilidades de ampliar, en tiempo de ejecución, el espacio lógico de un proceso. También comentamos algunos erro- res de programación típicos relacionados con el uso de la memoria. ## Página 6 GNUFDL • PID_00169383 6 La gestión de la memoria Objetivos Los materiales didácticos de este módulo contienen las herramientas necesa- rias para que el estudiante alcance los objetivos siguientes: 1. Justificar la existencia de diversos espacios de direcciones y de los meca- nismos de traducción de direcciones en tiempo de ejecución. 2. Conocer las funcionalidades que tienen que ofrecer los sistemas de gestión de la memoria en un sistema operativo multiproceso de propósito general. 3. Saber cómo se puede aumentar, en tiempo de ejecución, el espacio lógico de los procesos. ## Página 7 GNUFDL • PID_00169383 7 La gestión de la memoria 1.Espacios de direcciones La memoria física (RAM) del computador es un vector de palabras (típicamente del tamaño de un byte), cada una de las cuales se identifica mediante una dirección (@). En los sistemas operativos multiproceso, los procesos en ejecución (y el sistema operativo mismo) comparten la memoria física. Cada proceso (y el sistema operativo) tiene asignado un conjunto de direcciones físicas para almacenar su código, sus datos y su pila de ejecución. Ahora bien, el sistema operativo tiene que garantizar que ningún otro proceso podrá acceder al conjunto de direcciones asignado al resto de procesos (y al sistema operativo). Una posible solución pasa por considerar dos tipos de espacios de direcciones (el espacio físico y el espacio lógico) y un mecanismo de traducción de direc- ciones lógicas a direcciones físicas: 1)￿Espacio￿físico: está determinado por la memoria física instalada en el sis- tema computador. Las direcciones de memoria de este espacio se llaman di- recciones físicas. Asumiremos que el rango de direcciones físicas del espacio físico es lineal y que empieza en la dirección física 0 y finaliza a la dirección Memoria_Física_Instalada - 1. 2)￿Espacio￿lógico: este espacio es la visión que el sistema operativo ofrece del (1)En este módulo, mostramos las espacio físico. Cada proceso tiene asociado un espacio lógico, independien- direcciones lógicas y las direccio- nes físicas codificadas en hexadeci- te de los del resto de procesos, a través del cual puede acceder a su código, mal. a sus datos y a su pila de ejecución. Las direcciones de memoria de este es- pacio se llaman direcciones lógicas. Asumiremos que este espacio es lineal. Potencialmente, el rango de direcciones lógicas del espacio lógico empieza a la dirección lógica 0 y finaliza a la dirección 2Tamaño_Bus_Direcciones-1, donde Tamaño_Bus_Direcciones está determinada por el tamaño del bus de direccio- nes del procesador (típicamente, 32 o 64 bits en los procesadores actuales). Cabe destacar que, para cada proceso, existe un rango de direcciones lógicas válidas, que dependerá de la cantidad de memoria que utilice el proceso. La traducción de dirección lógica a dirección física dependerá del proceso que la realice; por ejemplo, la dirección lógica 0x0bc000001 puede ser traducida a direcciones físicas diferentes para cada proceso del sistema. Existen dos alternativas para implementar esta traducción de direcciones: ## Página 8 GNUFDL • PID_00169383 8 La gestión de la memoria 1)￿Estática (en tiempo de carga): al cargar un fichero ejecutable en la memoria se realiza la traducción de cada dirección lógica a la dirección física correspon- diente. Por lo tanto, cada dirección lógica se traduce una única vez a lo largo de la ejecución del programa. 2)￿Dinámica (en tiempo de ejecución): al cargar un fichero ejecutable en la memoria no se realiza ningún tipo de traducción. La ejecución del proceso hará que el procesador genere direcciones lógicas y un hardware especializa- do (la MMU, Memory Management Unit) traducirá cada dirección lógica en la dirección física correspondiente. A diferencia del caso anterior, en el que cada dirección lógica se traducía exactamente una vez, en este caso cada dirección lógica se traduce tantas veces como sea referenciada. Los sistemas operativos multiproceso actuales utilizan mecanismos basados en la traducción dinámica porque son más flexibles que los basados en la tra- ducción estática. ## Página 9 GNUFDL • PID_00169383 9 La gestión de la memoria 2.Un primer mecanismo de traducción dinámica A continuación, presentamos un mecanismo sencillo de traducción dinámica de direcciones. Aunque este mecanismo permite aislar el espacio lógico de un proceso (y del sistema operativo) de los del resto de procesos, veremos que tiene algunas limitaciones que lo convierten en inapropiado para los sistemas computadores actuales. Cada proceso tendrá asociado un espacio lógico. El rango de direcciones vá- lidas del espacio lógico del proceso i-ésimo será [0, tamañoi-1], donde tama- ñoi es el tamaño del espacio lógico del proceso i-ésimo (podemos asumir que coincide con la suma de los tamaños de sus regiones de código, datos y pila de ejecución). Cada proceso se cargará en una serie de posiciones consecutivas de la memoria física; basei será la dirección de memoria física base a partir de la cual se carga el proceso i-ésimo. La MMU de este sistema llevará a cabo dos tareas: • Comprobará que las direcciones lógicas (@L) generadas por un proceso se encuentren dentro del rango de direcciones válidas para el proceso. En caso de que una @L no sea válida, la MMU generará una excepción del tipo "acceso a memoria inválido". • Traducirá las direcciones lógicas en direcciones físicas (@F) mediante una suma de la dirección lógica con la dirección base. La MMU se programará con dos registros de control: • Base: indica la dirección física inicial asignada al proceso en ejecución. • Tamaño: indica el tamaño en bytes del espacio lógico del proceso en eje- cución. La figura 1 muestra el hardware que lleva a cabo estas tareas. El procesador genera direcciones lógicas para acceder al código, a los datos o a la pila alma- cenados en la memoria física. La MMU comprueba si la dirección lógica gene- rada es válida para el proceso (es decir, si pertenece al rango [0 ... tamaño-1]) utilizando un comparador. Si no está dentro del rango, la MMU genera una excepción del tipo "dirección lógica inválida" y no realiza ninguna traducción. Si se encuentra dentro del rango, suma la dirección lógica a la dirección física base y obtiene la dirección física. ## Página 10 GNUFDL • PID_00169383 10 La gestión de la memoria Figura 1. Esquema de una MMU sencilla que lleva a cabo traducción dinámica de direcciones y que permite aislar el espacio lógico de un proceso del resto de procesos. Con el fin de garantizar que el mecanismo aísle el rango de direcciones de Ved también un proceso del resto de procesos, las instrucciones del lenguaje máquina que permitan modificar el valor de los registros de control de la MMU tendrán que En el apartado 3 del módulo 2, encontraréis más información ser privilegiadas. Cada vez que cambie de contexto será necesario modificar el relacionada con las instruccio- nes privilegiadas del lenguaje valor de estos registros de control. máquina. La figura 2 presenta un ejemplo en el que asumimos que la memoria física instalada es (2)Como el espacio físico es de 220 de 1 MB (1.024 KB) y que está ocupada por el sistema operativo (256 KB a partir de la posiciones, cinco dígitos hexadeci- dirección 0x000002), por el proceso 1 (128 KB a partir de la dirección 0x80000) y por el males nos permiten codificar cual- proceso 2 (64 KB a partir de la dirección 0xC0000). quier dirección del espacio. Queremos crear un proceso (proceso 3) a partir de un ejecutable que define las regiones siguientes: código (64 KB), datos inicializados (16 KB), datos no inicializados (32 KB) Ved también y pila de ejecución (16 KB). Si se crea un proceso y se carga este fichero ejecutable en la memoria, el sistema operativo tiene que saber cuánta memoria necesita. La memoria Consultad el ejemplo de com- necesaria viene dada por el tamaño de las regiones de código, datos (inicializados y no pilación en el anexo del módu- inicializados) y pila. En este caso, serían necesarios 128 KB. lo didáctico 2. El sistema operativo tiene que buscar memoria física para incluir este proceso. Para con- seguirlo, necesitará alguna estructura de datos que represente el espacio libre en la me- moria física. Asumimos que el sistema operativo decide cargar el proceso en el rango de direcciones físicas que empieza a partir de la dirección 0x40000. El sistema operativo tendrá que guardar en alguna estructura de datos el tamaño (128 KB) y la dirección física base (0x40000) asociados a este nuevo proceso. Figura 2. Ejemplo en el que el sistema operativo y tres procesos comparten el espacio físico y en el que el mecanismo de traducción dinámica presentado en la sección 2 traduce las direcciones lógicas en direcciones físicas. ## Página 11 GNUFDL • PID_00169383 11 La gestión de la memoria Notad que cada proceso (y el sistema operativo) tiene un espacio lógico independiente del resto de procesos. Aunque aparentemente estos espacios lógicos están superpuestos (por ejemplo, en todos los espacios lógicos existe la dirección lógica 0x00FFF), el mecanismo de traducción los transforma en regiones disjuntas del espacio físico. Notad que el código almacenado en la memoria física utilizará direcciones lógicas (dentro del espacio lógico del proceso correspondiente) para codificar las direcciones de salto y las direcciones de rutinas. 2.1. Limitaciones de este sistema A causa de su simplicidad, este sistema de gestión de la memoria presenta una serie de problemas: 1)￿Contigüidad: el esquema presentado requiere que la memoria física en la que se carga un proceso sea contigua. Por ejemplo, en el ejemplo de la figura 2 no será posible cargar un proceso que necesite 200 KB porque, a pesar de disponer de 448 KB (128 KB + 128 KB + 192 KB) de memoria libre, no es posible encontrar un fragmento contiguo de 200 KB libres. Este problema se conoce con el nombre de fragmentación externa. Fragmentación externa El problema de la fragmentación externa también aparece en situaciones cotidianas, co- mo el aparcamiento de coches en línea en una calle que no señalice las plazas de aparca- miento. Aunque pueden existir diversos agujeros disponibles para estacionar un vehícu- lo, para poder aparcarlo es necesario que exista un agujero lo bastante grande para que quepa. La suma de los tamaños de los agujeros disponibles puede ser muy superior al tamaño del vehículo, pero no podremos aparcar el vehículo si el espacio libre necesario no está disponible de forma contigua. 2)￿Dificultad￿de￿crecimiento￿dinámico￿del￿espacio￿lógico￿de￿un￿proceso: algunos procesos pueden necesitar aumentar dinámicamente el tamaño de su espacio lógico para poder invocar procedimientos recursivos o para crear estructuras de datos en tiempos de ejecución. A causa de la contigüidad de este sistema de gestión de la memoria, para aumentar el espacio lógico del proceso habría que disponer de memoria física libre contigua a la que tiene asignada el proceso o bien, al cargar el proceso, reservar más memoria de la necesaria. En general, eso no siempre será factible. 3)￿No￿permite￿compartir￿porciones￿de￿código￿o￿datos￿entre￿diversos￿pro- cesos: si diversos procesos están ejecutando el mismo programa (por ejemplo, el intérprete de comandos o un editor de texto), no es razonable que el código esté replicado en la memoria física para cada proceso que lo está ejecutando. Sería más efectivo, si fuera posible, que el código estuviera cargado una única vez en la memoria física; los procesos compartirían este código y cada uno trabajaría con sus regiones de datos y de pila privadas. También sería factible que diversos procesos quisieran compartir un fragmento de su región de da- tos. El esquema presentado en este apartado no permite la compartición de memoria entre procesos. 4)￿No￿permite￿la￿carga￿de￿un￿proceso￿que￿no￿quepa￿en￿la￿memoria￿física. ## Página 12 GNUFDL • PID_00169383 12 La gestión de la memoria Por lo tanto, este sistema de gestión de la memoria no es adecuado para los sistemas operativos multiproceso de propósito general. En el apartado 3, da- remos las pinceladas básicas de un sistema de gestión de la memoria con tra- ducción dinámica que resuelve estos problemas. ## Página 13 GNUFDL • PID_00169383 13 La gestión de la memoria 3.Memoria virtual Existen diversas implementaciones posibles de un sistema de gestión de la memoria que resuelva los problemas del sistema presentado en el apartado anterior. En este apartado, presentaremos un sistema de gestión de la memoria basado en paginación, aunque hay otras alternativas. Veremos que este sistema permitirá independizar los procesos de la cantidad de memoria física instalada en la máquina, con lo cual será posible ejecutar procesos que requieran más memoria de la disponible. Se dice que estos sistemas ofrecen memoria virtual. 3.1. Paginación De forma transparente para el programador, un sistema de gestión de la me- (3)La arquitectura IA-32 de Intel moria basado en paginación divide el espacio lógico del proceso en trozos de utiliza páginas de un tamaño de 4 KB (212 bytes). tamaño fijo, que llamamos páginas3. El espacio físico también se divide en trozos del tamaño de una página, llamados frames. Este sistema de traducción ubicará cada página en un frame de memoria física. La figura 3 muestra un esquema del hardware que se necesita para implemen- tar la paginación. Figura 3. Esquema de una MMU que implementa paginación pura. El mecanismo de traducción divide las direcciones lógicas en dos componen- tes, que son el identificador de página lógica y el desplazamiento dentro de la página. Utilizando una tabla, llamada tabla de páginas, se determina el iden- tificador de frame en el espacio físico donde se encuentra la página lógica. Finalmente, se construye la dirección física concatenando el identificador de frame y el desplazamiento. ## Página 14 GNUFDL • PID_00169383 14 La gestión de la memoria División de las direcciones lógicas Como el procesador codifica las direcciones de memoria en base 2 y el tamaño de página es una potencia de 2 (2log2(tamaño_página)), la división de las direcciones lógicas en identifi- cador de página lógica y el desplazamiento dentro de la página se hace de forma trivial. El desplazamiento son los log2(tamaño_página) bits bajos de la dirección lógica y el iden- tificador de página lógica son el resto de bits de la dirección lógica. La tabla de páginas es propia de cada proceso y tiene tantas entradas como pá- (4)Como la granularidad de estas protecciones es la de la página, ginas pueda llegar a tener el espacio lógico de un proceso (2tamaño_bus_direcciones/ dentro de la misma página no se- tamaño_página). En cada una de las entradas se almacena un identificador de rá posible mezclar información co- rrespondiente a regiones diferen- frame y una serie de bits de control, entre los cuales está, como mínimo, el bit tes. de validez, que indica si esta página lógica pertenece al espacio lógico del pro- ceso. Otros bits de control posibles serían los bits de protección (read, readw- rite, execute), que indican qué operaciones es posible ejecutar en la página4. En caso de intentar acceder a una página lógica marcada como inválida en la tabla de páginas, se provocará una excepción que notificará este hecho al sis- tema operativo. Normalmente, esta excepción provocará que el sistema ope- rativo haga finalizar inmediatamente este proceso porque se considera que el proceso presenta un error de programación. Este sistema de gestión de la memoria presenta algunos problemas prácticos que complican su implementación real: • El tamaño de la tabla de páginas puede ser muy grande. Por ejemplo, si (5)Todos los procesos del sistema el tamaño del bus de direcciones es de 32 bits y el tamaño de la página tendrán una tabla de páginas de este tamaño, independientemen- es de 4 KB, la tabla de páginas tiene 220 entradas (1.048.576 entradas5). Si te de la cantidad de páginas que ocupe el proceso. El bit de validez cada entrada ocupa 4 bytes, representa 4 MB. Este tamaño resulta imprac- indicará qué entradas son las que ticable y son necesarias organizaciones que permitan reducir el tamaño de realmente utiliza el proceso. la tabla de páginas, como por ejemplo estructurar la tabla de páginas en (6)Es la solución adoptada por los dos niveles6. procesadores que implementan la arquitectura IA-32 de Intel. No es el objetivo de este documento pre- • A causa del tamaño, la tabla de páginas no se puede almacenar en registros sentar esta solución. y hay que almacenarla en la memoria7. Por lo tanto, cada referencia a la (7)La MMU tendrá un registro de memoria lógica implicaría dos accesos a la memoria física: uno a la tabla de control que indicará a partir de páginas y otro a la dirección física calculada. Este sobrecoste es inaceptable, qué posición de memoria física se encuentra la tabla de páginas del por lo que el hardware proporciona la TLB (Translation Lookaside Buffer), proceso en ejecución. una memoria caché especializada en almacenar las entradas de la tabla de páginas más utilizadas recientemente. Un sistema operativo que utilice la paginación necesitará una serie de estruc- turas de datos para llevar a cabo la gestión de la memoria. Además de las tablas de páginas de cada proceso (almacenadas en el espacio de datos del sistema operativo), será necesaria alguna estructura que indique si los frames de la me- moria física están libres u ocupados (tabla de frames) y algún procedimiento para obtener frames libres. ## Página 15 GNUFDL • PID_00169383 15 La gestión de la memoria 3.1.1. Ubicación de las regiones de código, datos y pila dentro del espacio lógico En el primer esquema presentado en el apartado 2, ubicábamos las regiones de código, datos y pila contiguamente dentro del espacio lógico. Utilizando la paginación, las regiones de código y de datos se ubican típica- mente en un extremo del espacio lógico, mientras que la de pila se ubica en el otro; todas las páginas intermedias estarán marcadas como inválidas. Esta distribución facilitará el hecho de que las regiones de datos y de pila del pro- ceso puedan crecer dinámicamente. Utilizando la paginación, este agujero en el espacio lógico no implica un des- perdicio de memoria física porque todas las páginas lógicas correspondientes al agujero están marcadas como inválidas, con lo cual no tendrán asociado ningún frame de memoria física. En cambio, en el esquema presentado en el apartado 2, esta disposición sí provocaría un desperdicio de memoria física. La figura 4 presenta un ejemplo en el que asumimos que el espacio lógico puede llegar a tener ocho páginas y el espacio físico tiene dieciséis frames. Cargamos dos ejecutables, el primero con dos páginas de código, una de datos y una de pila, y el segundo con tres de código, una de datos y una de pila. Ahora bien, el segundo ejecutable está cargado dos veces (dos usuarios diferentes están ejecutando este programa) y así demostraremos que no hay que duplicar el código en la memoria física. ## Página 16 GNUFDL • PID_00169383 16 La gestión de la memoria Figura 4. Ejemplo de carga de tres procesos en un sistema de gestión de la memoria paginado. Las páginas inválidas se han marcado con el símbolo -. La figura muestra los espacios lógicos correspondientes a los tres procesos, así como una posible carga de los procesos en el espacio físico y las tablas de páginas correspondientes. Notad que la paginación permite que los dos procesos compartan las páginas de código. 3.1.2. ¿Evita la paginación las deficiencias del sistema presentado en el apartado 2? Un mecanismo de gestión de la memoria basado en la paginación permite solucionar la mayoría de problemas descritos para el sistema anterior: 1) No es necesario que páginas contiguas en el espacio lógico tengan que serlo también en el espacio físico. Por lo tanto, la paginación no presenta el proble- ma de la fragmentación externa; cuando se carga un ejecutable en la memo- ria, es posible utilizar cualquier frame libre de memoria física, independiente- ## Página 17 GNUFDL • PID_00169383 17 La gestión de la memoria mente de si es contiguo o no con el resto de frames. En cambio, la paginación presenta otro problema, ya que la unidad mínima de asignación es la página, con lo cual las peticiones de memoria de tamaño no múltiple del tamaño de página provocarán un cierto desperdicio de memoria. Este problema se conoce como fragmentación interna y es inherente a todos los sistemas de almacena- miento (ya sea en memoria o en disco) que dividen el espacio en bloques de un tamaño fijo. Fragmentación interna El problema de la fragmentación interna también aparece en situaciones cotidianas, co- mo las reservas de mesas en los restaurantes. Típicamente, en una mesa no se mezclan comensales correspondientes a reservas diferentes (es decir, la mesa es la unidad mínima de asignación de espacio). Por lo tanto, aunque el restaurante puede tener sillas libres, éstas no se pueden asignar a nuevas reservas si estas sillas libres pertenecen a mesas ya asignadas a otras reservas. 2) La paginación permite que el espacio lógico de un proceso pueda crecer y decrecer. Gracias al agujero producido al ubicar los datos y la pila a cada extremo del espacio lógico, disponemos de páginas lógicas para poder variar el tamaño tanto de la región de datos como de la pila sin desperdiciar memoria física. 3) La paginación permite que diversos procesos compartan frames del espacio físico. Sólo es necesario que las entradas correspondientes de las tablas de pá- ginas de los procesos hagan referencia a estos frames compartidos. En cambio, la paginación no permite cargar procesos que no quepan en el Ved también espacio físico. En el subapartado 3.2, vere- mos cómo podemos extender 3.2. Paginación bajo demanda la paginación para poder car- gar estos procesos. Hasta ahora, todos los esquemas que hemos presentado partían de la base de que, cuando un proceso se ejecuta, es necesario que esté cargado totalmente en la memoria principal, pero eso no tiene que ser necesariamente así. La me- moria virtual es un esquema de gestión de la memoria con el que un proce- so puede estar sólo parcialmente cargado (residente) en la memoria principal. Con este esquema, la suma de los espacios lógicos de los procesos que se están ejecutando puede ser mayor que la memoria física disponible. El esquema también permite ejecutar procesos que tengan un espacio lógico mayor que el espacio físico, cosa que con los esquemas anteriores era imposi- ble. Este hecho se consigue manteniendo una imagen del espacio lógico del proceso en la memoria secundaria (disco) en una zona llamada área de inter- cambio (swap area). En cada instante, en la memoria principal sólo está carga- da la parte del proceso que es necesaria para su ejecución, o bien la parte del proceso que el sistema operativo permite cargar en la memoria. La decisión de qué parte del proceso se carga en la memoria y cuándo se carga la toma el sis- tema operativo y lo hace en función de la carga y la disponibilidad del sistema. ## Página 18 GNUFDL • PID_00169383 18 La gestión de la memoria La memoria virtual se puede implementar extendiendo la idea de paginación (figura 5). Esta extensión recibe el nombre de paginación￿bajo￿demanda. Hay que añadir un bit (bit de presencia) a cada entrada de la tabla de páginas para indicar si la página en cuestión está cargada o no en la memoria física. En caso de que no lo esté, se producirá una excepción del tipo "fallo de página" (page fault) y la rutina de atención tendrá que ir a buscar la página al área de inter- cambio, cargarla en la memoria principal, hacer que se repita el acceso en la memoria que ha provocado el fallo y hacer continuar la ejecución del proceso. Figura 5. Extensión de la MMU de la figura 3 con el fin de permitir el uso de memoria virtual. Además, es necesario que el sistema operativo disponga de algún tipo de es- tructura de datos que indique cómo está distribuido el proceso en el área de intercambio. La gestión más habitual es que en un principio no haya ninguna página car- gada en la memoria física y que las páginas del proceso se carguen a medida que se van necesitando. Cuando se ejecuta un proceso, cada referencia a la memoria lógica supone la ejecución de los pasos siguientes: • Primero, se comprueba si la página correspondiente a la dirección es válida con el bit de validez (v). • A continuación, se determina si la página está cargada en la memoria com- probando el bit de presencia (p). En caso de que no se encuentre en la me- moria, se genera un fallo de página y el sistema operativo tiene que hacer las gestiones necesarias con el fin de ir a buscar la página en el área de intercambio y cargarla en la memoria principal en un frame libre. La cosa se complica todavía más si no queda ningún frame libre, ya que entonces el sistema de gestión de la memoria tiene que quitar alguna página de la memoria principal y llevarla al disco, siempre que haya modificaciones. Además, tiene que actualizar la tabla de páginas del proceso al que perte- nece la página que se ha llevado al área de intercambio. Una vez el frame ## Página 19 GNUFDL • PID_00169383 19 La gestión de la memoria ya ha quedado libre, se puede asignar al proceso que se estaba ejecutando, actualizando su tabla de páginas. • Finalmente, si la página lógica es válida y presente, se genera la dirección física. Los sistemas de memoria virtual tienen que gestionar las páginas de la manera (8)En esta asignatura, no entrare- más eficiente posible a fin de que el tiempo de ejecución de los procesos no mos en detalle a considerar estas políticas. sea excesivamente alto a causa de un número muy grande de fallos de página. Es importante establecer buenas políticas8, como las siguientes: • Políticas￿de￿asignación￿de￿páginas: determinan cuántas páginas puede tener cargadas un proceso en la memoria física en un momento dado, es decir, determina lo que se llama working set. • Políticas￿de￿sustitución￿de￿páginas: estas políticas determinan qué frame conviene llevar al disco cuando se tiene que llevar una página a la memo- ria física y no quedan frames libres. ¿Hay que escoger entre los frames del mismo proceso que se está ejecutando? ¿O bien hay que considerar los frames de otros procesos? ¿Páginas que sólo se hayan leído? (en este caso se tendría que considerar que en cada entrada de la tabla de páginas o de la tabla de frames hay un bit que indica que la página se ha modificado). • Políticas￿de￿carga￿de￿páginas: determinan cuándo se cargan las páginas en la memoria. Existe la posibilidad de cargar páginas sólo cuando hay un fallo de página (paginación bajo demanda) o bien se puede intentar adelantar la carga de páginas aprovechando la localidad espacial de los programas (prefetching). Consideraciones finales: • Este mecanismo es totalmente transparente para el usuario. • Se ha comprobado que las referencias a la memoria hechas por un pro- grama no se distribuyen uniformemente por todas las páginas del espacio lógico. A causa de la localidad espacial y temporal de las referencias a la memoria, la mayoría de referencias se concentran en un conjunto reduci- do de páginas. Por lo tanto, la paginación bajo demanda no incrementa necesariamente el tiempo de ejecución del programa. • La memoria virtual permite incrementar el grado de multiprogramación porque, como cada proceso necesita menos memoria física, será posible cargar más procesos. De todas formas, aumentar excesivamente este grado puede afectar al rendimiento del sistema operativo (thrashing). • A lo largo de la ejecución de un proceso, una misma página se puede in- tercambiar del disco a la memoria y de la memoria al disco varias veces. ## Página 20 GNUFDL • PID_00169383 20 La gestión de la memoria Notad que cada vez que vuelve a la memoria física puede utilizar un frame diferente de memoria física (el sistema de gestión permite movilidad). ## Página 21 GNUFDL • PID_00169383 21 La gestión de la memoria 4.Modificación dinámica del espacio lógico En tiempo de ejecución, los procesos pueden tener que modificar el tamaño de su espacio lógico. Ahora bien, la forma de hacerlo depende de la región (código/datos/pila) de la que se quiera variar el tamaño. 1)￿Región￿de￿código: Existen diversas posibilidades para modificar dinámica- (9)En los sistemas Windows, tam- mente la región de código del espacio lógico de un proceso, como overlays, bién reciben el nombre de DLL (dynamic-link libraries). código automodificable o bibliotecas cargadas en tiempo de ejecución9. Salvo las bibliotecas cargadas en tiempo de ejecución, estas opciones están en desuso o se utilizan únicamente en escenarios muy concretos. En esta asignatura, no vamos a considerar ninguna de estas opciones. 2)￿Región￿de￿pila￿de￿ejecución: La pila es transparente para el programador (10)El sistema operativo puede limi- de aplicaciones de alto nivel. Al crear cada proceso, el sistema operativo le tar el tamaño máximo que puede llegar a alcanzar la pila de ejecu- asigna un tamaño inicial de pila. Si en algún momento este tamaño resulta ción de los procesos. insuficiente (el proceso ejecuta una instrucción push que intenta escribir más allá del tamaño asignado a la pila), la MMU generará una excepción. La rutina de atención a la excepción comprobará si el problema es debido al tamaño de la pila y, a ser posible10, aumentará el tamaño y permitirá que el proceso repita la ejecución de la instrucción push y continúe su ejecución. Por lo tanto, el crecimiento de la región de pila es completamente transparente para el pro- gramador y tampoco nos ocuparemos de él. 3)￿Región￿de￿datos: el tamaño de la región de datos es responsabilidad del programador. Éste dispondrá de llamadas al sistema con el fin de poder mo- dificar dinámicamente esta región del espacio lógico. Eso puede resultar útil porque el tamaño de algunas estructuras de datos puede depender de un valor desconocido en tiempo de compilación y que no se conocerá hasta el tiempo de ejecución del programa. En esta asignatura, nos centraremos en cómo mo- dificar dinámicamente el tamaño de esta región. 4.1. Modificación dinámica del tamaño de la región de datos El sistema operativo acostumbra a ofrecer llamadas al sistema para aumentar y disminuir la región de datos del espacio lógico del proceso. En el caso del Unix, ambas tareas se pueden hacer con la llamada al sistema brk. Desgraciadamente, esta llamada tiene una interfaz poco intuitiva y pre- senta algunos problemas de portabilidad. Por lo tanto, no es habitual que los programas utilicen directamente esta llamada al sistema. ## Página 22 GNUFDL • PID_00169383 22 La gestión de la memoria La biblioteca del lenguaje C ofrece diversas rutinas para modificar el tamaño de la región de datos: calloc, malloc, free y realloc. Las rutinas calloc, malloc y realloc permiten ampliar la región de datos, pero difieren en la interfaz. La rutina free permite liberar la memoria obtenida previamente con calloc/ma- lloc/realloc. Por ejemplo, la interfaz de la rutina malloc es void *malloc(size_t size) y recibe como parámetro la cantidad de bytes en los que queremos ampliar la región de datos. Si no es posible realizar esta operación, la rutina devuelve el puntero NULL; de lo contrario, devuelve la dirección lógica de la memoria correspon- diente al primer byte que se ha añadido en la región de datos y el resto de bytes se encuentran en posiciones de memoria consecutivas. La interfaz de la rutina free es void free(void *ptr) y recibe como parámetro una dirección de memoria obtenida previamente con calloc/malloc/realloc. A continuación, mostramos un par de fragmentos de código en los que se crean dinámicamente un vector (figura 6) y una matriz (figura 7). int *vector; vector = malloc(N*sizeof(int)); /* Pide espacio para N enteros */ if (vector == NULL) error("Memoria no disponible"); for (i=0; i GNUFDL • PID_00169383 23 La gestión de la memoria 5.Errores de programación relacionados con el acceso a la memoria Finalmente, haremos algunas consideraciones sobre los errores de programa- ción relacionados con el acceso a la memoria, es decir, los errores de progra- mación que provocan que un proceso acceda a una dirección de memoria a la que no tendría que acceder. Son especialmente típicos de programas escritos en lenguaje C o C++. La figura 8 muestra algunos ejemplos de estos errores. Figura 8. Ejemplo de algunos errores de programación relacionados con el ac- ceso a la memoria int vector[10]; unsigned int n; char s[10]; int *k; char *p; /* Error de programación si n >= 10 */ vector[n] = valor; /* Error de programación porque la memoria intermedia s es demasiado pequeña (buffer overflow) */ sprintf(s, "El valor de vector[3] es %d\n", vector[3]); /* Error de programación porque no tiene sentido referenciar variables locales de un procedimiento una vez éste ha acabado */ int *rut() { int n; n = valor; return(&n); } ... k = rut(); n = *k; /* Error de programación porque se accede a memoria liberada */ p = malloc(100); ... free(p); p[4] = valor; En general, el compilador de lenguaje C no puede detectar estos tipos de erro- res. Además, pueden ser muy difíciles de localizar por el programador porque: • Es posible que, para la mayoría de datos de entrada, estos errores no afecten al comportamiento correcto del programa. ## Página 24 GNUFDL • PID_00169383 24 La gestión de la memoria • Pueden manifestarse muchas sentencias más allá de la que ha realizado el acceso erróneo. • Pueden manifestarse (o no) en función de las versiones del sistema opera- tivo/compilador/bibliotecas y demás, así como de los parámetros de com- pilación o de los datos de entrada del proceso, entre otros. En los apartados anteriores, hemos visto que la MMU detecta accesos a la me- moria inválidos, pero tenemos que tener en cuenta que: • La MMU no podrá detectar un error de programación que provoque el ac- (11)Esta biblioteca guarda informa- ceso a otra dirección válida del proceso. Por lo tanto, el proceso puede leer ción en el espacio lógico de cada usuario que la utiliza. o modificar datos que no tienen nada que ver con la operación que se está realizando. Por ejemplo, un acceso a la memoria incorrecto puede estar modificando datos de control de la biblioteca de entrada/salida11, cosa que puede provocar un error de ejecución la siguiente vez que utilicemos una rutina de esta biblioteca. • En un sistema basado en la paginación, si el tamaño de las regiones de código/datos/pila no es múltiplo del tamaño de página, podemos tener páginas marcadas como válidas en las que no todas las direcciones de estas páginas son correctas desde el punto de vista del programador. La MMU no podrá detectar un acceso incorrecto dentro de esta página. Los accesos incorrectos pueden producirse en cualquier modo de ejecución (privilegiado y no privilegiado), pero el tratamiento es diferente. 1)￿Modo￿de￿ejecución￿no￿privilegiado: si la MMU determina que un acceso (12)El usuario puede indicar si quie- es inválido, la MMU provocará una excepción. La rutina del sistema operativo re que se generen estos ficheros y qué tamaño máximo pueden te- que atiende esta excepción hace abortar el proceso. En el caso del Unix, la ner. rutina de atención acostumbra a crear un fichero12 llamado core en el que se almacena el estado completo del proceso (contenido de los registros y de la memoria) en el momento que se provoca la excepción. Este fichero se po- drá examinar posteriormente con el depurador (debugger). Cuando un proceso creado desde el intérprete de comandos ha sido abortado a causa de un acceso a memoria inválido, los intérpretes de comandos del Unix suelen mostrar el mensaje Segmentation fault. Core dumped (error de segmentación). 2)￿Modo￿de￿ejecución￿privilegiado: siempre que alguna llamada al sistema (13)Por ejemplo, si un proceso in- tiene que acceder a algún rango de direcciones lógicas del proceso13, antes el voca la llamada al sistema write del Unix, la rutina de atención ten- sistema operativo comprueba por software que este rango de direcciones sea drá que leer datos de un fichero y escribirlos en el espacio lógico del válido para el proceso. El código del sistema operativo accederá a estas direc- usuario, en el rango de direcciones ciones únicamente si la comprobación indica que todo el rango de direcciones especificado por una dirección ló- gica inicial y un tamaño. es válido; ahora bien, aunque el rango de direcciones sea válido, no quiere de- cir que el acceso a la memoria sea correcto desde el punto de vista del progra- mador. En el caso de que alguna dirección del rango sea inválida, la llamada al ## Página 25 GNUFDL • PID_00169383 25 La gestión de la memoria sistema no se realizará y devolverá el código de error adecuado. Si, a pesar de todo, la MMU detecta un acceso a la memoria inválido en modo de ejecución privilegiado, por precaución el sistema operativo suele dejar de prestar servicio y aparece un Kernel panic (Linux) o la Blue screen of death (Windows). Para ayudar a los programadores a detectar o corregir estos tipos de errores, existen herramientas como: • depuradores (debuggers), que permiten analizar los ficheros core, • versiones sofisticadas de las bibliotecas de asignación de memoria diná- mica. Es importante que los programas no presenten estos tipos de errores. Hay que pensar que una cantidad significativa de ataques a sistemas informáticos apro- vechan un tipo particular de estos errores (los buffer overflows). ## Página 26 GNUFDL • PID_00169383 26 La gestión de la memoria Resumen En este módulo didáctico, hemos visto la manera como el sistema operativo, con la ayuda del hardware, puede ofrecer una visión de la memoria idealizada a los procesos en ejecución. Mientras que la memoria física está limitada y es compartida por todos los procesos, la visión que tendrá cada proceso es que dispone de un espacio de direcciones no compartido con ningún otro proceso, independientemente de la ocupación actual de la memoria física y que puede tener un tamaño mayor que la memoria física instalada. El sistema operativo realiza esta tarea de forma transparente para los procesos utilizando mecanis- mos de traducción dinámicos (en tiempo de ejecución) implementados den- tro de un hardware especializado llamado MMU (Memory Management Unit). ## Página 27 GNUFDL • PID_00169383 27 La gestión de la memoria Actividades 1. Explicad la diferencia que existe entre fragmentación interna y fragmentación externa. 2. Se quiere reducir la fragmentación interna en un sistema de gestión de la memoria basado en la paginación reduciendo el tamaño de las páginas (por ejemplo, de 4 KB a 1 KB). ¿Qué impacto tiene esta reducción en el tamaño de la tabla de páginas de los procesos? 3. En la figura 3 no se especifica el número de bits que circula por cada línea del circuito de traducción. Determinadlo asumiendo que el tamaño de página es de 4 KB, que el bus de direcciones es de 32 bits y que la cantidad máxima de memoria física instalada es de 2 GB. 4. El operador & del lenguaje C se aplica a una variable y nos devuelve la dirección de me- moria donde se almacena. ¿Esta dirección es lógica o física? 5. Buscad información sobre la manera como Linux estructura el espacio lógico en los proce- sadores IA-32 de Intel. ¿Dónde ubica Linux las regiones de código, datos y pila de un proceso? ¿Por qué creéis que, a partir de la dirección lógica 0xC0000000, todos los espacios lógicos tienen el mismo contenido (código, datos y pila del sistema operativo)? ¿Por qué creéis que el código del programa no se empieza a cargar a partir de la dirección lógica 0x00000000? 6. Buscad información sobre la estructura de dos niveles de la tabla de páginas aplicada por los procesadores que implementan la arquitectura IA-32 de Intel. 7. Buscad información sobre cuáles son los bits de control presentes en las entradas de las tablas de página de los procesadores que implementan la arquitectura IA-32 de Intel. 8. En un sistema paginado con memoria virtual queremos controlar mediante un bit (dirty bit) si una página ha sido modificada. ¿En qué tabla situaríais este bit: en la tabla de páginas del proceso, en la tabla de frames o en la tabla de páginas del disco? 9. ¿En un sistema paginado podemos afirmar que la MMU detectará todos los accesos a la memoria en una posición de memoria incorrecta (por ejemplo, un acceso más allá del tamaño de un vector)? 10. Buscad información sobre los stack overflows. ¿En qué consisten? ¿Por qué son peligrosos? Buscad información sobre el Execute-Disable (NX) bit que algunos procesadores Intel incor- poran en la tabla de páginas. Ejercicios de autoevaluación 1. Disponemos de una máquina con un espacio lógico de procesador de 1.024 Kbytes y una Nota memoria física instalada de 128 Kbytes. El sistema de gestión de la memoria del sistema operativo instalado en esta máquina se basa en la técnica de la paginación bajo demanda, en la que las páginas tienen un tamaño de 2 Kbytes. Inicialmente, el proceso no tiene ninguna Por espacio lógico de procesador página cargada en la memoria. Suponemos que en una página sólo habrá o bien código, o entendemos el tamaño máxi- bien datos del proceso, o bien la pila de ejecución del proceso. mo que puede llegar a tener el espacio lógico de un proceso. En esta máquina queremos ejecutar un programa. La cabecera del ejecutable de este programa nos indica que el código del programa ocupa 10 Kbytes, que tenemos 6 Kbytes de datos inicializados, que los datos no inicializados ocuparán 15 Kbytes y que la pila tiene 12 Kbytes. La cabecera del ejecutable ocupa 128 bytes. Con esta información, contestad a las preguntas siguientes: a) ¿Podéis decir aproximadamente el tamaño que tendrá el fichero ejecutable del programa que hemos descrito? Si el tamaño de las páginas de la memoria fuera de 1 Kbyte, ¿cuál sería el tamaño del fichero ejecutable? b) Una vez cargado este programa y creado el espacio lógico del proceso correspondiente y suponiendo que todas las páginas que ocupa el proceso estuvieran presentes en la memoria física, ¿cuál sería la cantidad de memoria física que ocuparía nuestro proceso? Responded a la misma pregunta considerando que las páginas fueran de 1 Kbyte. c) ¿Cuál es la fragmentación interna que produciría este proceso en caso de que las páginas fueran de 2 Kbytes? ¿Y si fueran de 1 Kbyte? d) ¿Qué efecto tendría un cambio en la cantidad de memoria física instalada que tiene esta máquina sobre los espacios de direcciones siguientes: fichero ejecutable, espacio lógico del procesador y espacio lógico del proceso? ## Página 28 GNUFDL • PID_00169383 28 La gestión de la memoria 2. Suponemos que una máquina tiene un sistema de gestión de la memoria en el que la traducción de direcciones se efectúa dinámicamente (en ejecución) y que ofrece memoria virtual. Contestad a las preguntas siguientes justificando brevemente vuestra respuesta. a) ¿Puede ser mayor el tamaño del espacio lógico de un proceso que la cantidad total de la memoria física instalada en la máquina? b) ¿Qué efecto tendría un aumento de la cantidad de memoria física instalada sobre el tamaño del espacio lógico del procesador? c) ¿Es posible que la misma dirección lógica de dos procesos diferentes sea traducida en la misma dirección física en un mismo momento? d) ¿Es posible que una dirección lógica de un programa en ejecución sea traducida en direc- ciones físicas diferentes en diferentes instantes de la misma ejecución? e) ¿Es necesario que la pila de ejecución de un proceso se almacene en direcciones lógicas consecutivas? ¿Y en direcciones físicas consecutivas? f) Compilamos un mismo programa de dos maneras diferentes; en la primera, indicamos que el tamaño inicial de la pila será de 10 K y en la segunda indicamos que será de 20 K. ¿Cuál creéis que será la diferencia de tamaño entre los dos ficheros ejecutables generados? g) ¿Permite ampliar el grado de multiprogramación el hecho de disponer de la memoria virtual? 3. Contestad a las preguntas siguientes: a) ¿Puede el espacio lógico del procesador ser mayor que la suma de los tamaños de la me- moria física instalada y del dispositivo de almacenamiento (área de intercambio) de páginas sacadas de la memoria física? b) ¿Puede el espacio lógico del proceso ser mayor que la suma de los tamaños de la memoria física instalada y del tamaño del dispositivo de almacenamiento (disco) de páginas sacadas de la memoria física? c) ¿Tiene cualquier proceso de usuario partes de su espacio lógico de proceso que tienen que encontrarse permanentemente en la memoria física durante la ejecución del proceso? d) Si durante la ejecución concurrente de dos procesos ambos intentan acceder a la misma dirección lógica, ¿quiere decir que están compartiendo la memoria? ## Página 29 GNUFDL • PID_00169383 29 La gestión de la memoria Solucionario Ejercicios de autoevaluación 1.a) Un ejecutable está formado por el código y los datos inicializados. La pila y los datos no inicializados se crean en tiempo de ejecución. Así pues, el tamaño del ejecutable es igual al tamaño de la cabecera + el tamaño del código + el tamaño de los datos inicializados (128 bytes + 10 Kbytes + 6 Kbytes). En el caso de páginas de memoria de 1 Kbyte, el tamaño del ejecutable sería el mismo porque es independiente del tamaño de la página. b) Con páginas de 2 Kbytes, el tamaño de la memoria física ocupado sería igual en 22 páginas (44 Kbytes) y, con páginas de 1 Kbyte, el tamaño sería igual a 43 páginas (43 Kbytes). c) Con páginas de 2 Kbytes, tendríamos una fragmentación interna de 1 Kbyte y con páginas de 1 Kbyte no habría fragmentación interna. d) No les afectaría de ningún modo. 2.a) Sí, ya que el sistema de gestión de la memoria permite ejecutar procesos sin que todo el espacio lógico esté en la memoria física simultáneamente. b) Ninguno, ya que el espacio lógico del procesador está determinado por los bits de dirección de memoria de los que dispone el procesador. c) Sí, en el caso de que los dos procesos estén compartiendo código o datos. d) Sí, ya que el sistema de gestión permite que una página se pueda mover dentro de la memoria física. e) Es necesario que se encuentre en direcciones lógicas consecutivas, pero no hace falta que esté en direcciones físicas consecutivas. f) Los ejecutables tendrán el mismo tamaño, ya que en el ejecutable se guarda información del tamaño inicial de la pila, pero no se reserva espacio. g) Sí, ya que en un sistema no entero no hay que tener todo el espacio lógico de los procesos simultáneamente en la memoria física y, por lo tanto, permite que entren más. 3.a) Puede ser mayor porque el espacio lógico del procesador sólo depende del número de bits que tiene el bus de direcciones del procesador. b) El espacio lógico de un proceso no puede ser mayor que la suma de los tamaños de estas dos zonas. c) Un sistema de gestión de la memoria que sea no entero permite que todo el espacio lógico de un proceso (código, datos y pila) esté en el disco durante la ejecución. A medida que se van referenciando páginas, la rutina de atención en el fallo de página ya las irá llevando del disco a la memoria física. Las estructuras de datos del sistema operativo (tablas de páginas y otras informaciones relativas al proceso) no forman parte del espacio lógico de proceso. d) No necesariamente, porque procesos diferentes tienen programaciones de gestores de la memoria diferentes; por lo tanto, los dos pueden generar la misma dirección lógica, pero la traducción dinámica puede hacer que esta dirección lógica vaya a parar a direcciones físicas diferentes. ## Página 30 GNUFDL • PID_00169383 30 La gestión de la memoria Glosario bit de presencia  m  Bit utilizado en los sistemas de gestión de la memoria virtual para indicar si el fragmento del espacio lógico del proceso al que se hace referencia está cargado en la memoria. bit de validez  m  Bit utilizado en los sistemas de gestión de la memoria para indicar si el fragmento del espacio lógico al que se hace referencia pertenece al espacio lógico del proceso. fallo de página  f  Excepción generada por la MMU en un sistema de gestión de la memoria que ofrece memoria virtual cuando el procesador genera una dirección lógica que se traduce en una página válida, pero que no está cargada (no está presente) en la memoria física. fragmentación externa  f  Espacios de memoria no utilizables que se crean en sistemas de gestión de la memoria en los que los procesos se cargan en posiciones de la memoria física contiguas. Tiene lugar cuando no hay un espacio de memoria contiguo libre lo bastante grande para cargar un proceso, aunque haya trozos libres más pequeños cuya suma de las capacidades sería suficiente para cargarlo. fragmentación interna  f  Espacios de memoria no utilizables que se crean cuando la memoria se divide en partes de tamaño fijo (por ejemplo, frames de memoria principal o bloques de disco) y una de estas partes se asigna a un conjunto de datos más pequeño que la capacidad de la parte en cuestión. hiperpaginación  m  Situación que se da cuando la memoria disponible en un momento dado para la ejecución de un proceso es inferior a la mínima necesaria (working set) para su ejecución, lo que provoca una elevada actividad de intercambio. Un sistema se encuentra en thrashing si se pasa más tiempo intercambiando páginas que ejecutando código de las aplicaciones. Una causa habitual es que el grado de multiprogramación es excesivamente elevado para la configuración del hardware. en thrashing intercambio  m  Acción de llevar páginas de un proceso de la memoria secundaria (disco) a la memoria principal o swap in. El proceso inverso, es decir, el hecho de llevar páginas de un proceso desde la memoria principal hasta la secundaria, se llama swap out. en swapping memoria virtual  f  Sistema de gestión de la memoria que permite ejecutar un proceso a pesar de tener sólo parte del proceso cargada en la memoria. Mediante técnicas como la paginación bajo demanda, el sistema irá cargando otras partes del proceso a medida que se necesiten. paginación  f  Sistema de gestión de la memoria que divide el espacio lógico y el espacio físico en bloques de tamaño fijo y asigna a cada bloque del espacio lógico (página) un bloque del espacio físico (frame). ## Página 31 GNUFDL • PID_00169383 31 La gestión de la memoria Bibliografía Silberschatz, A.; Galvin; Gagne, G. (2008). Operating Systems Concepts (8.ª ed.). John Wiley & Sons. Tanembaum, A. (2009). Modern Operating Systems. Prentice-Hall. ## Página 32