4.3. Conceptos b�sicos sobre Memoria Virtual
A�n cuando la tecnolog�a detr�s de la construcci�n de las implementaciones modernas de almacenamiento es realmente impresionante, el administrador de sistemas promedio no necesita estar al tanto de los detalles. De hecho, solamente existe un factor que los administradores de sistemas deber�an tener en consideraci�n:
Nunca hay suficiente RAM.
Mientras que esta frase puede sonar al principio un poco c�mica, muchos dise�adores de sistemas operativos han empleado una gran cantidad de tiempo tratando de reducir el impacto de esta limitaci�n. Esto lo han logrado mediante la implementaci�n de la memoria virtual — una forma de combinar RAM con un almacenamiento m�s lento para darle al sistema la apariencia de tener m�s RAM de la que tiene instalada realmente.
4.3.1. La memoria virtual en t�rminos sencillos
Vamos a comenzar con una aplicaci�n hipot�tica. El c�digo de m�quina que conforma esta aplicaci�n tiene un tama�o de 10000 bytes. Tambi�n requiere otros 5000 bytes para el almacenamiento de datos y para la memoria intermedia de E/S. Esto significa que para ejecutar la aplicaci�n, deben haber m�s de 15000 bytes de RAM disponible; un byte menos y la aplicaci�n no ser� capaz de ejecutarse.
Este requerimiento de 15000 bytes se conoce como el espacio de direcciones de la aplicaci�n. Es el n�mero de direcciones �nicas necesarias para almacenar la aplicaci�n y sus datos. En las primeras computadoras, la cantidad de RAM disponible ten�a que ser mayor que el espacio de direcciones de la aplicaci�n m�s grande a ejecutar; de lo contrario, la aplicaci�n fallar�a con un error de "memoria insuficiente".
Un enfoque posterior conocido como solapamiento intent� aliviar el problema permitiendo a los programadores dictar cuales partes de sus aplicaciones necesitaban estar residentes en memoria en cualquier momento dado. De esta forma, el c�digo requerido solamente para prop�sitos de inicializaci�n pod�a ser sobreescrito con c�digo a utilizar posteriormente. Mientras que el solapamiento facilit� las limitaciones de memoria, era un proceso muy complejo y susceptible a errores. El solapamiento tambi�n fallaba en solucionar el problema de las limitaciones de memoria globales al sistema en tiempo de ejecuci�n. En otras palabras, un programa con solapamiento requer�a menos memoria para ejecutarse que un programa sin solapamiento, pero si el sistema no tiene suficiente memoria para el programa solapado, el resultado final es el mismo — un error de falla de memoria.
Con la memoria virtual el concepto del espacio de direcciones de las aplicaciones toma un significado diferente. En vez de concentrarse en cuanta memoria necesita una aplicaci�n para ejecutarse, un sistema operativo con memoria virtual continuamente trata de encontrar una respuesta a la pregunta "qu� tan poca memoria necesita la aplicaci�n para ejecutarse?".
Aunque inicialmente pareciera que nuestra aplicaci�n hipot�tica requiere de un total de 15000 bytes para ejecutarse, recuerde nuestra discusi�n anterior en la Secci�n 4.1 — el acceso a memoria tiende a ser secuencial y localizado. Debido a esto, la cantidad de memoria requerida para ejecutar la aplicaci�n en un momento dado es menos que 15000 bytes — usualmente mucho menos. Considere los tipos de accesos de memoria requeridos para ejecutar una instrucci�n de m�quina sencilla:
La instrucci�n es le�da desde la memoria.
Se leen desde memoria los datos requeridos por la instrucci�n.
Despu�s de completar la instrucci�n, los resultados de la instrucci�n son escritos nuevamente en memoria.
El n�mero real de bytes necesarios para cada acceso de memoria var�an de acuerdo a la arquitectura del CPU, la instrucci�n misma y el tipo de dato. Sin embargo, a�n si una instrucci�n requiere de 100 bytes de memoria por cada tipo de acceso de memoria, los 300 bytes requeridos son mucho menos que el espacio de direcciones total de la aplicaci�n de 15000 bytes. Si hubiese una forma de hacer un seguimiento de los requerimientos de memoria de la aplicaci�n a medida que esta se ejecuta, ser�a posible mantener la aplicaci�n ejecut�ndose usando menos memoria que lo que indicar�a su espacio de direcciones.
Pero esto genera una pregunta:
Si solamente una parte de la aplicaci�n est� en memoria en un momento dado, d�nde esta el resto?
4.3.2. Almacenamiento de respaldo — el Tenet central de la memoria virtual
La respuesta corta a esta pregunta es que el resto de la aplicaci�n se mantiene en disco. En otras palabras, el disco act�a como un almacenamiento de respaldo para la RAM; un medio m�s lento y tambi�n m�s grande que act�a como un "respaldo" para un almacenamiento m�s r�pido y m�s peque�o. Esto puede parecer al principio como un gran problema de rendimiento en su creaci�n — despu�s de todo, las unidades de disco son mucho m�s lentas que la RAM.
Aunque esto es cierto, es posible tomar ventaja del comportamiento de acceso secuencial y localizado de las aplicaciones y eliminar la mayor�a de las implicaciones de rendimiento en el uso de unidades de disco como unidades de respaldo para la RAM. Esto se logra estructurando el subsistema de memoria virtual para que este trate de asegurarse de que esas partes de la aplicaci�n que actualmente se necesitan — o que probablemente se necesitaran en un futuro cercano — se mantengan en RAM solamente por el tiempo en que son realmente requeridas.
En muchos aspectos, esto es similar a la situaci�n entre la cach� y la RAM: haciendo parecer una poca cantidad de almacenamiento r�pido con grandes cantidades de un almacenamiento lento actuar como que si se tratase de grandes cantidades de almacenamiento r�pido.
Con esto en mente, exploremos el proceso en m�s detalle.
