Los softwares se ejecutan en el sistema operativo con una premisa muy simple: requieren memoria. El sistema operativo del dispositivo lo proporciona en forma de RAM. La cantidad de memoria requerida puede variar: algunos softwares necesitan una gran cantidad de memoria, otros requieren poca memoria. La mayoría (si no todos) de los usuarios ejecutan varias aplicaciones en el sistema operativo simultáneamente, y dado que la memoria es cara (y el tamaño del dispositivo es finito), la cantidad de memoria disponible siempre es limitada. Entonces, dado que todos los softwares requieren una cierta cantidad de RAM, y todos pueden ejecutarse al mismo tiempo, el sistema operativo tiene que encargarse de dos cosas:
- Que el software siempre se ejecuta hasta que el usuario lo cancela, es decir, no debe abortar automáticamente porque el sistema operativo se ha quedado sin memoria.
- La actividad anterior, manteniendo un rendimiento respetable para el software en ejecución.
Ahora la pregunta principal se reduce a cómo se gestiona la memoria. ¿Qué rige exactamente en qué parte de la memoria residirán los datos que pertenecen a un software determinado?
Posible solución 1 : Deje que los softwares individuales especifiquen explícitamente la dirección de memoria que usarán en el dispositivo. Suponga que Photoshop declara que siempre usará direcciones de memoria que van desde 0
hasta 1023
(imagine la memoria como una matriz lineal de bytes, por lo que el primer byte está en la ubicación 0
, el 1024
byte está en la ubicación 1023
), es decir, ocupando 1 GB
memoria. De manera similar, VLC declara que ocupará el rango de memoria 1244
para 1876
, etc.
Ventajas:
- Cada aplicación tiene asignada previamente una ranura de memoria, de modo que cuando se instala y ejecuta, simplemente almacena sus datos en esa área de memoria y todo funciona bien.
Desventajas:
Esto no escala. Teóricamente, una aplicación puede requerir una gran cantidad de memoria cuando está haciendo algo realmente pesado. Por lo tanto, para asegurarse de que nunca se quede sin memoria, el área de memoria asignada siempre debe ser mayor o igual a esa cantidad de memoria. ¿Qué pasa si un software, cuyo uso de memoria teórico máximo es 2 GB
(por lo tanto, requiere 2 GB
la asignación de memoria de la RAM), se instala en una máquina con solo 1 GB
memoria? ¿Debería el software simplemente abortar al inicio, diciendo que la RAM disponible es menor que 2 GB
? ¿O debería continuar, y en el momento en que se exceda la memoria requerida 2 GB
, simplemente abortar y salir con el mensaje de que no hay suficiente memoria disponible?
No es posible evitar la alteración de la memoria. Hay millones de software, incluso si a cada uno de ellos se le asignara solo 1 kB
memoria, la memoria total requerida excedería 16 GB
, que es más de lo que ofrecen la mayoría de los dispositivos. Entonces, ¿cómo se pueden asignar espacios de memoria a diferentes softwares que no invadan las áreas de los demás? En primer lugar, no existe un mercado de software centralizado que pueda regular que cuando se lanza un nuevo software, debe asignarse a sí mismo tanta memoria de esta área aún desocupada., y en segundo lugar, aunque lo hubiera, no es posible hacerlo porque el no. de softwares es prácticamente infinito (por lo tanto, requiere una memoria infinita para acomodarlos a todos), y la RAM total disponible en cualquier dispositivo no es suficiente para acomodar ni siquiera una fracción de lo que se requiere, lo que hace inevitable la invasión de los límites de memoria de un software sobre el de otro. Entonces, ¿qué sucede cuando Photoshop se asigna posiciones de memoria 1
de 1023
e VLC se asigna 1000
a 1676
? ¿Qué pasa si Photoshop almacena algunos datos en la ubicación 1008
, luego VLC los sobrescribe con sus propios datos y luego Photoshop?accede pensando que son los mismos datos que se tenían almacenados allí anteriormente? Como puedes imaginar, sucederán cosas malas.
Así que claramente, como puede ver, esta idea es bastante ingenua.
Posible solución 2 : Probemos con otro esquema, donde el SO hará la mayor parte de la administración de la memoria. Los softwares, siempre que requieran memoria, solo solicitarán el sistema operativo, y el sistema operativo se adaptará en consecuencia. Digamos que el sistema operativo asegura que cada vez que un nuevo proceso solicita memoria, asignará la memoria desde la dirección de byte más baja posible (como se dijo anteriormente, la RAM se puede imaginar como una matriz lineal de bytes, por lo que para una 4 GB
RAM, el rango de direcciones para una byte de 0
a2^32-1
) si el proceso está comenzando, de lo contrario, si es un proceso en ejecución que solicita la memoria, se asignará desde la última ubicación de memoria donde ese proceso aún reside. Dado que el software emitirá direcciones sin considerar cuál será la dirección de memoria real donde se almacenan los datos, el sistema operativo tendrá que mantener un mapeo, por software, de la dirección emitida por el software a la dirección física real (Nota: Esa es una de las dos razones por las que llamamos a este concepto Virtual Memory
. Los softwares no se preocupan por la dirección de memoria real donde se almacenan sus datos, simplemente escupen direcciones sobre la marcha y el sistema operativo encuentra el lugar correcto para ubicarlo y encontrarlo. más tarde si es necesario).
Digamos que el dispositivo se acaba de encender, el sistema operativo se acaba de lanzar, en este momento no hay ningún otro proceso en ejecución (¡ignorando el sistema operativo, que también es un proceso!), Y decide iniciar VLC . Entonces, a VLC se le asigna una parte de la RAM de las direcciones de byte más bajas. Bueno. Ahora, mientras se ejecuta el video, debe iniciar su navegador para ver alguna página web. Luego, debe iniciar el Bloc de notas para garabatear texto. Y luego Eclipse para hacer un poco de codificación .. Muy pronto su memoria de 4 GB
se agota, y la RAM se ve así:
Problema 1: Ahora no puede iniciar ningún otro proceso, ya que toda la RAM está agotada. Por lo tanto, los programas deben escribirse teniendo en cuenta el máximo de memoria disponible (¡prácticamente incluso habrá menos disponible, ya que otros softwares también se ejecutarán en paralelo!). En otras palabras, no puede ejecutar una aplicación que consuma mucha memoria en su destartalada 1 GB
PC.
Bien, ahora decide que ya no necesita mantener abiertos Eclipse y Chrome , los cierra para liberar algo de memoria. El sistema operativo recupera el espacio ocupado en la RAM por esos procesos, y ahora se ve así:
Suponga que cerrar estos dos libera 700 MB
espacio - ( 400
+ 300
) MB. Ahora necesita iniciar Opera , que ocupará 450 MB
espacio. Bueno, tienes más 450 MB
espacio disponible en total, pero ... no es contiguo, está dividido en partes individuales, ninguna de las cuales es lo suficientemente grande para caber 450 MB
. Entonces, se te ocurrió una idea brillante, movamos todos los procesos de abajo a lo más arriba posible, lo que dejará el 700 MB
espacio vacío en un trozo en la parte inferior. Se llamacompaction
. Genial, excepto que ... todos los procesos que hay se están ejecutando. Moverlos significará mover la dirección de todo su contenido (recuerde, el sistema operativo mantiene un mapeo de la memoria escupida por el software a la dirección de memoria real. Imagine que el software ha escupido una dirección 45
con datos 123
y el sistema operativo la ha almacenado en la ubicación 2012
y creó una entrada en el mapa, mapeando 45
a 2012
. Si el software ahora se mueve en la memoria, lo que solía estar en la ubicación 2012
ya no estará en 2012
, sino en una nueva ubicación, y el sistema operativo tiene que actualizar el mapa en consecuencia para asignar 45
a la nueva dirección, para que el software pueda obtener los datos esperados ( 123
) cuando consulta la ubicación de la memoria 45
. En lo que respecta al software, todo lo que sabe es esa dirección45
contiene los datos 123
!)! Imagine un proceso que hace referencia a una variable local i
. Para cuando se accede de nuevo, su dirección ha cambiado y ya no podrá encontrarlo. Lo mismo se aplicará a todas las funciones, objetos, variables, básicamente todo tiene una dirección, y mover un proceso significará cambiar la dirección de todos ellos. Lo que nos lleva a:
Problema 2: no puede mover un proceso. Los valores de todas las variables, funciones y objetos dentro de ese proceso tienen valores codificados como los escupió el compilador durante la compilación, el proceso depende de que estén en la misma ubicación durante su vida útil y cambiarlos es costoso. Como resultado, los procesos dejan grandes " holes
" cuando salen. A esto se le llama
External Fragmentation
.
Multa. Supongamos que de alguna manera, de alguna manera milagrosa, logras mover los procesos hacia arriba. Ahora hay 700 MB
espacio libre en la parte inferior:
Opera encaja suavemente en la parte inferior. Ahora tu RAM se ve así:
Bueno. Todo luce bien. Sin embargo, no queda mucho espacio, y ahora debe iniciar Chrome nuevamente, ¡un conocido acaparador de memoria! Necesita mucha memoria para empezar, y casi no le queda ... Excepto ... ahora nota que algunos de los procesos, que inicialmente ocupaban un gran espacio, ahora no necesitan mucho espacio. Es posible que haya detenido su video en VLC , por lo tanto, todavía ocupa algo de espacio, pero no tanto como se requiere mientras ejecuta un video de alta resolución. Lo mismo ocurre con el Bloc de notas y las fotos . Su RAM ahora se ve así:
Holes
, ¡Una vez más! ¡Volver al punto de partida! Excepto que, anteriormente, los agujeros ocurrieron debido a la terminación de los procesos, ¡ahora se debe a que los procesos requieren menos espacio que antes! Y nuevamente tiene el mismo problema, la holes
combinación produce más espacio del requerido, pero están dispersos, no son de gran utilidad de forma aislada. Por lo tanto, debe mover esos procesos nuevamente, una operación costosa y muy frecuente, ya que los procesos con frecuencia se reducirán de tamaño durante su vida útil.
Problema 3: Los procesos, a lo largo de su vida útil, pueden reducir su tamaño, dejando atrás espacio no utilizado, que si es necesario utilizarlo, requerirá la costosa operación de mover muchos procesos. A esto se le llama
Internal Fragmentation
.
Bien, ahora, su sistema operativo hace lo necesario, mueve los procesos e inicia Chrome y, después de un tiempo, su RAM se ve así:
Frio. Ahora suponga que vuelve a seguir viendo Avatar en VLC . ¡Su requisito de memoria se disparará! Pero ... no queda espacio para que crezca, ya que el Bloc de notas está acurrucado en la parte inferior. Entonces, nuevamente, ¡todos los procesos deben moverse hacia abajo hasta que VLC haya encontrado suficiente espacio!
Problema 4: si los procesos necesitan crecer, será una operación muy costosa
Multa. Ahora suponga que se está utilizando Fotos para cargar algunas fotos desde un disco duro externo. El acceso al disco duro lo lleva del ámbito de las cachés y la RAM al del disco, que es más lento en varios órdenes de magnitud. Dolorosamente, irrevocablemente, trascendentalmente más lento. Es una operación de E / S, lo que significa que no está vinculada a la CPU (es exactamente lo contrario), lo que significa que no necesita ocupar RAM en este momento. Sin embargo, sigue ocupando RAM obstinadamente. Si desea iniciar Firefox mientras tanto, no puede, porque no hay mucha memoria disponible, mientras que si Photos se hubiera sacado de la memoria durante la duración de su actividad de E / S, habría liberado mucha memoria. seguido de la compactación (cara), seguida de la instalación de Firefox .
Problema 5: Los trabajos vinculados de E / S siguen ocupando RAM, lo que lleva a una infrautilización de la RAM, que podría haber sido utilizada por trabajos vinculados a la CPU mientras tanto.
Entonces, como podemos ver, tenemos tantos problemas incluso con el enfoque de la memoria virtual.
Hay dos enfoques para abordar estos problemas: paging
y segmentation
. Discutamos paging
. En este enfoque, el espacio de direcciones virtuales de un proceso se asigna a la memoria física en fragmentos, llamados pages
. Un page
tamaño típico es 4 kB
. El mapeo se mantiene mediante algo llamado a page table
, dada una dirección virtual, todo lo que tenemos que hacer ahora es averiguar a qué page
dirección pertenece, luego desde el page table
, encontrar la ubicación correspondiente para eso page
en la memoria física real (conocida como frame
), y dado que el desplazamiento de la dirección virtual dentro del page
es el mismo para el page
y el frame
, averigüe la dirección real agregando ese desplazamiento a la dirección devuelta por el page table
. Por ejemplo:
A la izquierda está el espacio de direcciones virtuales de un proceso. Digamos que el espacio de direcciones virtuales requiere 40 unidades de memoria. Si el espacio de direcciones físicas (a la derecha) también tuviera 40 unidades de memoria, habría sido posible mapear todas las ubicaciones desde la izquierda a una ubicación a la derecha, y hubiéramos estado muy felices. Pero por mala suerte, la memoria física no solo tiene menos (24 aquí) unidades de memoria disponibles, ¡también debe compartirse entre múltiples procesos! Bien, veamos cómo nos las arreglamos.
Cuando se inicia el proceso, digamos que se realiza una solicitud de acceso a la memoria para la ubicación 35
. Aquí el tamaño de la página es 8
(cada uno page
contiene 8
ubicaciones, todo el espacio de direcciones virtuales de 40
ubicaciones contiene 5
páginas). Entonces esta ubicación pertenece a la página no. 4
( 35/8
). Dentro de esto page
, esta ubicación tiene un desplazamiento de 3
( 35%8
). Entonces esta ubicación puede ser especificada por la tupla (pageIndex, offset)
= (4,3)
. Esto es solo el comienzo, por lo que ninguna parte del proceso se almacena todavía en la memoria física real. Entonces page table
, el , que mantiene un mapeo de las páginas de la izquierda a las páginas reales de la derecha (donde se llamanframes
) está actualmente vacío. Entonces, OS renuncia a la CPU, permite que un controlador de dispositivo acceda al disco y obtenga la página no. 4
para este proceso (básicamente un fragmento de memoria del programa en el disco cuyas direcciones van de 32
a 39
). Cuando llega, el sistema operativo asigna la página en algún lugar de la RAM, por ejemplo, el primer marco en sí, y page table
para este proceso se toma nota de que la página se 4
asigna a un marco 0
en la RAM. Ahora los datos finalmente están allí en la memoria física. El sistema operativo vuelve a consultar la tabla de páginas para la tupla (4,3)
, y esta vez, la tabla de páginas dice que la página 4
ya está asignada al marco 0
en la RAM. Entonces, el sistema operativo simplemente va al 0
th frame en RAM, accede a los datos en el desplazamiento 3
en ese frame (Tómese un momento para comprender esto.page
, que se obtuvo del disco, se mueve a frame
. Entonces, sea cual sea el desplazamiento de una ubicación de memoria individual en una página, también será el mismo en el marco, ya que dentro de page
/ frame
, ¡la unidad de memoria aún reside en el mismo lugar relativamente!), ¡Y devuelve los datos! Debido a que los datos no se encontraron en la memoria en la primera consulta, sino que tuvieron que ser recuperados del disco para cargarlos en la memoria, constituye un error .
Multa. Ahora suponga que se realiza un acceso a la memoria para la ubicación 28
. Todo se reduce a (3,4)
. Page table
ahora tiene una sola entrada, mapeo de página 4
a marco 0
. Así que esto es nuevamente un error , el proceso renuncia a la CPU, el controlador del dispositivo obtiene la página del disco, el proceso recupera el control de la CPU nuevamente y page table
se actualiza. Digamos que ahora la página 3
está asignada a un marco 1
en la RAM. Así se (3,4)
convierte (1,4)
, y se devuelven los datos en esa ubicación en la RAM. Bueno. De esta forma, suponga que el siguiente acceso a la memoria es para la ubicación 8
, que se traduce en (1,0)
. La página 1
aún no está en la memoria, se repite el mismo procedimiento y page
se asigna en el marco2
en RAM. Ahora el mapeo del proceso RAM se parece a la imagen de arriba. En este momento, la RAM, que tenía solo 24 unidades de memoria disponibles, está llena. Suponga que la siguiente solicitud de acceso a la memoria para este proceso es de address 30
. Se asigna (3,6)
y page table
dice que la página 3
está en RAM y se asigna al marco 1
. ¡Hurra! Entonces, los datos se obtienen de la ubicación de la RAM (1,6)
y se devuelven. Esto constituye un acierto , ya que los datos requeridos se pueden obtener directamente de la RAM, por lo que es muy rápido. Del mismo modo, las próximas solicitudes de acceso, dicen para lugares 11
, 32
, 26
, 27
todos son éxitos , es decir, los datos solicitados por el proceso se encuentra directamente en la memoria RAM sin necesidad de buscar en otra parte.
Ahora suponga que 3
llega una solicitud de acceso a la memoria para la ubicación . Se traduce (0,3)
, y page table
para este proceso, que actualmente cuenta con 3 entradas, para las páginas 1
, 3
y 4
dice que esta página no está en la memoria. Al igual que en los casos anteriores, se obtiene del disco, sin embargo, a diferencia de los casos anteriores, ¡la RAM está llena! Entonces, ¿qué hacer ahora? Aquí radica la belleza de la memoria virtual, ¡se desaloja un fotograma de la RAM! (Varios factores gobiernan qué marco se va a desalojar. Puede LRU
basarse, dónde se va a desalojar el marco al que se accedió menos recientemente para un proceso. Puede ser la first-come-first-evicted
base, dónde se desaloja el marco que se asignó hace más tiempo, etc. .) Entonces se desaloja algún marco. Diga el cuadro 1 (simplemente seleccionándolo al azar). Sin embargo, eso frame
se asigna a algunospage
! (Actualmente, está asignado por la tabla de páginas a la página 3
de nuestro único proceso). Entonces en ese proceso hay que contar esta trágica noticia, que uno frame
, que desgraciadamente te pertenece, va a ser desalojado de RAM para dejar espacio a otro pages
. El proceso tiene que asegurarse de que se actualice page table
con esta información, es decir, eliminar la entrada para ese dúo de marcos de página, de modo que la próxima vez que se haga una solicitud para eso page
, le diga al proceso que esto page
ya no está en la memoria. y tiene que ser recuperado del disco. Bueno. Por lo tanto, el marco 1
se expulsa, la página 0
se introduce y se coloca allí en la RAM, y la entrada para la página 3
se elimina y se reemplaza por la 0
asignación de página al mismo marco.1
. Así que ahora nuestro mapeo se ve así (observe el cambio de color en el segundo frame
en el lado derecho):
¿Vio lo que acaba de pasar? El proceso tenía que crecer, necesitaba más espacio que la RAM disponible, pero a diferencia de nuestro escenario anterior donde todos los procesos en la RAM tenían que moverse para adaptarse a un proceso en crecimiento, ¡aquí sucedió con un solo page
reemplazo! Esto fue posible gracias al hecho de que la memoria de un proceso ya no necesita ser contigua, puede residir en diferentes lugares en fragmentos, el sistema operativo mantiene la información sobre dónde están y, cuando es necesario, se consultan adecuadamente. Nota: podría estar pensando, eh, ¿qué pasa si la mayoría de las veces es a miss
, y los datos deben cargarse constantemente desde el disco a la memoria? Sí, teóricamente, es posible, pero la mayoría de los compiladores están diseñados de tal manera que siguelocality of reference
, es decir, si se utilizan datos de alguna ubicación de la memoria, los siguientes datos necesarios se ubicarán en algún lugar muy cercano, tal vez del mismo page
, page
que se acaba de cargar en la memoria. Como resultado, la próxima falla ocurrirá después de bastante tiempo, la mayoría de los próximos requisitos de memoria serán satisfechos por la página que se acaba de traer o las páginas que ya están en la memoria y que se usaron recientemente. El mismo principio exacto nos permite desalojar también el que se ha utilizado menos recientemente page
, con la lógica de que lo que no se ha utilizado en un tiempo, probablemente no se utilice también en un tiempo. Sin embargo, no siempre es así y, en casos excepcionales, eso sí, el rendimiento puede verse afectado. Más sobre esto más adelante.
Solución al problema 4: Los procesos ahora pueden crecer fácilmente, si se enfrenta un problema de espacio, todo lo que se requiere es hacer un page
reemplazo simple , sin mover ningún otro proceso.
Solución al problema 1: un proceso puede acceder a memoria ilimitada. Cuando se necesita más memoria de la disponible, el disco se usa como respaldo, los nuevos datos requeridos se cargan en la memoria desde el disco y los datos usados menos recientemente frame
(o page
) se mueven al disco. Esto puede continuar infinitamente, y dado que el espacio en disco es barato y virtualmente ilimitado, da la ilusión de memoria ilimitada. Otra razón para el nombre Virtual Memory
, ¡te da una ilusión de memoria que realmente no está disponible!
Frio. Anteriormente nos enfrentábamos a un problema en el que, aunque un proceso se reduce de tamaño, el espacio vacío es difícil de recuperar por otros procesos (porque requeriría una compactación costosa). Ahora es fácil, cuando un proceso se vuelve más pequeño, muchos de pages
ellos ya no se utilizan, por lo que cuando otros procesos necesitan más memoria, un LRU
desalojo basado simple desaloja automáticamente los menos utilizados pages
de la RAM y los reemplaza con las nuevas páginas de los otros procesos (y por supuesto la actualización page tables
de todos esos procesos así como el proceso original que ahora requiere menos espacio), ¡todo esto sin ninguna operación de compactación costosa!
Solución al Problema 3: Siempre que los procesos reduzcan su tamaño, su frames
RAM será menos utilizada, por lo que un simple LRU
desalojo basado puede desalojar esas páginas y reemplazarlas con las pages
requeridas por nuevos procesos, evitando así Internal Fragmentation
sin necesidad compaction
.
En cuanto al problema 2, tómese un momento para comprender esto, ¡el escenario en sí está completamente eliminado! No es necesario mover un proceso para acomodar un nuevo proceso, porque ahora todo el proceso nunca necesita ajustarse a la vez, solo ciertas páginas deben ajustarse ad hoc, eso sucede al desalojar frames
de la RAM. Todo sucede en unidades de pages
, por lo tanto, no hay concepto de hole
ahora y, por lo tanto, no se trata de que nada se mueva. May be 10 pages
tuvo que ser movido debido a este nuevo requisito, hay miles de los pages
cuales quedan intactos. Mientras que, antes, ¡todos los procesos (cada parte de ellos) tenían que moverse!
Solución al problema 2: para dar cabida a un nuevo proceso, los datos de las partes de otros procesos que se han utilizado menos recientemente deben desalojarse según sea necesario, y esto ocurre en unidades de tamaño fijo llamadas pages
. Por lo tanto, no hay posibilidad de hole
o External Fragmentation
con este sistema.
Ahora, cuando el proceso necesita realizar alguna operación de E / S, ¡puede ceder la CPU fácilmente! El sistema operativo simplemente lo desaloja todo pages
de la RAM (quizás lo almacene en algún caché) mientras que los nuevos procesos ocupan la RAM mientras tanto. Cuando se realiza la operación de E / S, el sistema operativo simplemente los restaura pages
a la RAM (por supuesto, reemplazando el pages
de algunos otros procesos, puede ser de los que reemplazaron el proceso original, o puede ser de algunos que ellos mismos necesitan hacer I / O ¡Oh ahora, y por lo tanto puedo renunciar a la memoria!)
Solución al problema 5: cuando un proceso está realizando operaciones de E / S, puede abandonar fácilmente el uso de RAM, que pueden utilizar otros procesos. Esto conduce a una utilización adecuada de la RAM.
Y, por supuesto, ahora ningún proceso accede directamente a la RAM. Cada proceso accede a una ubicación de memoria virtual, que se asigna a una dirección de RAM física y se mantiene mediante page-table
ese proceso. El mapeo está respaldado por el sistema operativo, el sistema operativo le permite al proceso saber qué marco está vacío para que se pueda instalar una nueva página para un proceso. Dado que esta asignación de memoria es supervisada por el propio sistema operativo, puede garantizar fácilmente que ningún proceso invada el contenido de otro proceso asignando solo marcos vacíos de la RAM, o al invadir el contenido de otro proceso en la RAM, comunicarse con el proceso. para actualizarlo page-table
.
Solución al problema original: No hay posibilidad de que un proceso acceda al contenido de otro proceso, ya que el sistema operativo administra toda la asignación y cada proceso se ejecuta en su propio espacio de direcciones virtuales en un espacio aislado.
Entonces paging
(entre otras técnicas), junto con la memoria virtual, ¡es lo que impulsa los softwares actuales que se ejecutan en sistemas operativos! Esto libera al desarrollador de software de preocuparse por la cantidad de memoria disponible en el dispositivo del usuario, dónde almacenar los datos, cómo evitar que otros procesos corrompan los datos de su software, etc. Sin embargo, por supuesto, no es una prueba completa. Hay fallas:
Paging
es, en última instancia, dar al usuario la ilusión de memoria infinita al usar el disco como respaldo secundario. Recuperar datos del almacenamiento secundario para que quepan en la memoria (se llama page swap
, y se llama al evento de no encontrar la página deseada en la RAM page fault
) es costoso ya que es una operación de E / S. Esto ralentiza el proceso. Varios de estos intercambios de páginas ocurren sucesivamente y el proceso se vuelve dolorosamente lento. ¿Alguna vez ha visto su software funcionando bien y de manera elegante, y de repente se vuelve tan lento que casi se cuelga o no le deja otra opción que reiniciarlo? Posiblemente se estaban produciendo demasiados cambios de página, lo que lo hacía lento (llamado thrashing
).
Volviendo a OP,
¿Por qué necesitamos la memoria virtual para ejecutar un proceso? - Como la respuesta explica en detalle, para dar a los softwares la ilusión de que el dispositivo / sistema operativo tiene memoria infinita, de modo que cualquier software, grande o pequeño, se puede ejecutar, sin preocuparse por la asignación de memoria u otros procesos que corrompan sus datos, incluso cuando corriendo en paralelo. Es un concepto, implementado en la práctica a través de varias técnicas, una de las cuales, como se describe aquí, es Paging . También puede ser segmentación .
¿Dónde se encuentra esta memoria virtual cuando el proceso (programa) del disco duro externo se lleva a la memoria principal (memoria física) para la ejecución? - La memoria virtual no se encuentra en ningún lugar per se, es una abstracción, siempre presente, cuando se inicia el software / proceso / programa, se crea una nueva tabla de páginas para él y contiene el mapeo de las direcciones escupidas por ese proceso a la dirección física real en RAM. Dado que las direcciones escupidas por el proceso no son direcciones reales, en cierto sentido, son, en realidad, lo que se puede decir the virtual memory
.
¿Quién se ocupa de la memoria virtual y cuál es el tamaño de la memoria virtual? - Es atendido, en conjunto, por el SO y el software. Imagine una función en su código (que finalmente se compila y se convierte en el ejecutable que generó el proceso) que contiene una variable local: an int i
. Cuando el código se ejecuta, i
obtiene una dirección de memoria dentro de la pila de la función. Esa función se almacena en sí misma como un objeto en otro lugar. Estas direcciones son generadas por el compilador (el compilador que compiló su código en el ejecutable) - direcciones virtuales. Cuando se ejecuta, i
tiene que residir en algún lugar de la dirección física real durante la duración de esa función al menos (¡a menos que sea una variable estática!), Por lo que el sistema operativo asigna la dirección virtual generada por el compilador dei
en una dirección física real, de modo que siempre que, dentro de esa función, algún código requiera el valor de i
, ese proceso puede consultar al SO para esa dirección virtual, y el SO a su vez puede consultar la dirección física por el valor almacenado y devolverlo.
Suponga que si el tamaño de la RAM es de 4 GB (es decir, 2 ^ 32-1 espacios de direcciones), ¿cuál es el tamaño de la memoria virtual? - El tamaño de la RAM no está relacionado con el tamaño de la memoria virtual, depende del sistema operativo. Por ejemplo, en Windows de 32 bits, lo es 16 TB
, en Windows de 64 bits, lo es 256 TB
. Por supuesto, también está limitado por el tamaño del disco, ya que es allí donde se realiza la copia de seguridad de la memoria.