¿Cuáles son las diferencias entre la memoria virtual y la memoria física?

Los softwares se ejecutan en el sistema operativo en 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 memoria enorme, algunos requieren memoria insignificante. La mayoría (si no todos) los usuarios ejecutan múltiples 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. Así que dado que todos los softwares requieren una cierta cantidad de RAM, y todos ellos se puede hacer que se ejecute al mismo tiempo, OS tiene que cuidar de dos cosas:

1. Que el software siempre se ejecuta hasta que el usuario lo aborta, es decir, no debe abortar automáticamente porque el sistema operativo se ha quedado sin memoria.
2. La actividad anterior, manteniendo un rendimiento respetable para los softwares en ejecución.

Ahora la pregunta principal se reduce a cómo se administra la memoria. Qué gobierna exactamente dónde en la memoria los datos que pertenecen a un dado ¿reside el software?

Solución posible 1 : Deje que los softwares individuales especifiquen explícitamente la dirección de memoria que utilizarán en el dispositivo. Supongamos que Photoshop declara que siempre utilizará direcciones de memoria que van desde 0 a 1023 (imagine la memoria como una matriz lineal de bytes, por lo que el primer byte está en la ubicación 0, 1024th byte is at location 1023) - i.e. occupying 1 GB memory. Del mismo modo, VLC declara que ocupará memoria intervalo 1244 a 1876, etc.

Ventajas:

1. A cada aplicación se le asigna previamente una ranura de memoria, por lo que cuando se instala y ejecuta, solo almacena sus datos en esa área de memoria, y todo funciona bien.

Desventajas:

1. Esto no escala. Teóricamente, una aplicación puede requerir una gran cantidad de memoria cuando está haciendo algo realmente pesado. Así que para asegurarse de que nunca se queda sin memoria, el área de memoria asignado a él siempre debe ser mayor o igual a esa cantidad de memoria. ¿Qué pasa si un software, cuyo uso teórico máximo de memoria es 2 GB (por lo tanto requiere 2 GB asignación de memoria de RAM), se instala en una máquina con solo 1 GB memoria? En caso de que el software acaba de abortar en el inicio, diciendo que la RAM disponible es inferior a 2 GB? O si continúa, y en el momento en que la memoria requerida excede 2 GB, simplemente aborta y bail out con el mensaje de que no hay suficiente memoria disponible?

2. No es posible prevenir la destrucción de la memoria. Hay millones de softwares por ahí, 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 la mayoría de los dispositivos ofrecen. Entonces, ¿cómo se pueden asignar ranuras de memoria a diferentes softwares que no invadan las áreas de los demás? En primer lugar, no hay un mercado de software centralizado que pueda regular que cuando se lanza un nuevo software, debe asignarse esta cantidad de memoria de este área aún desocupada, y en segundo lugar, incluso si lo hubiera, no es posible hacerlo porque el no. of softwares es prácticamente infinito (por lo tanto requiere memoria infinita para acomodar todos ellos), y la RAM total disponible en cualquier dispositivo no es suficiente para acomodar incluso 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é pasa cuando Photoshop es asignar ubicaciones de memoria 1 a 1023 y VLC es asignado 1000 a 1676? ¿Qué pasa si Photoshop almacena algunos datos en la ubicación 1008, luego VLC sobrescribe eso con sus propios datos, y luego Photoshop accede pensando que son los mismos datos que se habían almacenado allí anteriormente? Como puedes imaginar, sucederán cosas malas.

Tan claramente, como se puede ver, esta idea es más bien ingenuo.

Posible solución 2 : Probemos con otro esquema - donde el sistema operativo hará la mayor parte de la gestión de memoria. Los softwares, siempre que necesiten memoria, solo solicitarán el sistema operativo, y el sistema operativo se acomodará en consecuencia. Say OS asegura que cada vez que un nuevo proceso solicita memoria, asignará la memoria desde la dirección de bytes más baja posible (como se dijo anteriormente, la RAM se puede imaginar como una matriz lineal de bytes, por lo que para una RAM 4 GB, las direcciones range for a byte from 0 to 2^32-1) if the process is starting, else if it is a running process requesting the memory, it will allocate from the last memory location where that process still resides. Dado que los softwares emitirán direcciones sin considerar cuál será la dirección de memoria real donde se almacenarán esos datos, el sistema operativo tendrá que mantener una asignación, 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 adecuado para encajarla y encontrarla más tarde si es necesario).

Digamos que el dispositivo acaba de encenderse, el sistema operativo acaba de iniciarse, en este momento no hay otro proceso en ejecución (ignorando el sistema operativo, que también es un proceso!), y usted decide lanzar VLC . So VLC se asigna una parte de la RAM de las direcciones de bytes más bajas. Bien. Ahora, mientras se ejecuta el video, debe iniciar su navegador para ver alguna página web. Entonces necesitas lanzar Bloc de notas para garabatear algo de texto. Y luego Eclipse para hacer algo de codificación.. Muy pronto tu memoria de 4 GB se agotará, y la RAM se verá así:

Problema 1: Ahora no puede iniciar ningún otro proceso, para toda la RAM se agota. Por lo tanto, los programas deben escribirse teniendo en cuenta la máxima memoria disponible (¡prácticamente incluso menos estará disponible, ya que otros softwares también se ejecutarán en paralelo!). En otras palabras, no puede ejecutar una aplicación que consume mucha memoria en su destartalado PC 1 GB.

Bien, así que ahora decides que ya no necesitas mantener Eclipsey Chrome abiertos, los cierras para liberar algo de memoria. El espacio ocupado en RAM por esos procesos es reclamado por el sistema operativo, y se ve así ahora:

Supongamos que estos dos liberan 700 MB espacio - (400 + 300) MB. Ahora necesita lanzar Opera, que ocupará 450 MB espacio. Bueno, tienes más de 450 MB espacio disponible en total, but...it no es contiguo, se divide en trozos individuales, ninguno de los cuales es lo suficientemente grande como para caber 450 MB. Así que le diste a un idea brillante, vamos a mover todos los procesos de abajo a lo más arriba posible, lo que dejará el espacio vacío 700 MB en un trozo en la parte inferior. Esto se llama compaction. Genial, excepto eso...todos los procesos que hay se están ejecutando. Moverlos significará mover la dirección de todos sus contenidos (recuerde, el sistema operativo mantiene una asignación de la memoria escupida por el software a la dirección de memoria real. Imagine software había escupido una dirección de 45 con datos 123, y el sistema operativo lo había almacenado en location 2012 y creado una entrada en el mapa, mapeando 45 a 2012. Si el software ahora se mueve en memoria, lo que solía estar en la ubicación 2012 ya no estará en 2012, sino en una nueva ubicación, y OS tiene que actualizar el mapa en consecuencia para mapear 45 a la nueva dirección, de modo que el software pueda obtener los datos esperados (123) cuando consulte la ubicación de la memoria 45. En lo que respecta al software, todo lo que sabe es que la dirección 45 contiene los datos 123!)! Imagine un proceso que hace referencia a una variable locali. En el momento en que se accede de nuevo, su dirección ha cambiado, y no será capaz de encontrarlo más. Lo mismo ocurrirá con todas las funciones, objetos, variables, básicamente todo tiene una dirección, y mover un proceso significará cambiar la dirección de todas ellas. Lo que nos lleva a:

Problema 2: No se puede mover un proceso. Los valores de todas las variables, funciones y objetos dentro de eso proceso tienen valores codificados como escupido por el compilador durante la compilación, el proceso depende de estar en el mismo lugar durante su vida útil, y cambiarlos es caro. Como resultado, los procesos dejan atrás big " holes" cuando salen. Esto se llama External Fragmentation.

Bien. Supongamos que de alguna manera, de alguna manera milagrosa, se las arregla para mover los procesos hacia arriba. Ahora hay 700 MB de espacio libre en el abajo:

Opera encaja suavemente en la parte inferior. Ahora su RAM se ve así:

Bien. Todo se ve bien. Sin embargo, no queda mucho espacio, y ahora tienes que lanzar Chrome de nuevo, un conocido memory-hog! Necesita mucha memoria para empezar, y apenas te queda...Excepto.. ahora observe que algunos de los procesos, que inicialmente ocupaban un gran espacio, ahora no necesitan mucho espacio. Puede ser que haya detenido su video en VLC , por lo tanto, todavía está ocupando algo de espacio, pero no tanto como se requiere mientras se ejecuta un video de alta resolución. De manera similar para Bloc de notas y Fotos. Su RAM ahora se ve así:

Holes, ¡una vez más! Volver a square uno! Excepto que, anteriormente, los agujeros se producían debido a procesos que terminaban, ahora se debe a procesos que requieren menos espacio que antes! Y otra vez tienes el mismo problema, el holes rendimiento combinado más espacio del requerido, pero están dispersos alrededor, no mucho de uso en aislamiento. Así que tienes que mover esos procesos de nuevo, una operación costosa, y muy frecuente, ya que los procesos con frecuencia se reducirán en tamaño durante su vida útil.

Problema 3: Los procesos, a lo largo de su vida útil, pueden reducir su tamaño, dejando espacio sin usar, que si es necesario usar, requerirá la costosa operación de mover muchos procesos. Esto se llama Internal Fragmentation.

Bien, así que ahora, su sistema operativo hace lo necesario, mueve los procesos y comienza Chrome y después de algún tiempo, su RAM se ve así:

Genial. Ahora supongamos que usted vuelve a ver Avatar in VLC . Su requisito de memoria se disparará! Pero...no queda espacio para que crezca, ya que el bloc de notas está acurrucado en su parte inferior. Así que, de nuevo, todos los procesos tienen que moverse hacia abajo hasta que VLC haya encontrado suficiente espacio!

Problema 4: Si los procesos necesitan crecer, será una operación muy costosa

Bien. Ahora supongamos, Fotos se está utilizando para cargar algunas fotos de un disco duro externo. Acceder al disco duro te lleva del reino de las cachés y la RAM al del disco, que es más lento por órdenes de magnitudes. Dolorosamente, irrevocablemente, trascendentalmente más lento. Es una operación de E / S, lo que significa que no está vinculada a la CPU (es más bien lo contrario), lo que significa que no necesita ocupar RAM en este momento. Sin embargo, todavía ocupa 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 enlazada de E/S, habría liberado mucha memoria, seguido de compactación (costosa), seguido de Firefox encajando.

Problema 5: Los trabajos vinculados a E / S siguen ocupando RAM, lo que lleva a una infrautilización de RAM, que podría haber sido utilizada por los trabajos vinculados a CPU mientras tanto.

Así que, como podemos ver, tenemos muchos problemas incluso con el enfoque de memoria virtual.

Existen dos enfoques para abordar estos problemas - paging y segmentation. Vamos a discutir paging. En este enfoque, el espacio de direcciones virtuales de un proceso se asigna a la memoria física en trozos, llamados pages. Un típico page el tamaño es 4 kB. El mapeo es mantenido por algo llamado page table, dada una dirección virtual, todo lo que tenemos que hacer ahora es averiguar cuál page la dirección pertenece, entonces, a partir de la page table, encontrar la ubicación correspondiente para que page en la memoria física real (conocido como frame), y dado que el desplazamiento de la dirección virtual dentro de la page es el mismo para el page así como la frame, averiguar la dirección real, agregando que el desplazamiento de la dirección devuelta por el page table. Para 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) tuviera 40 unidades de memoria también, habría sido posible mapear toda la ubicación desde la izquierda a una ubicación a la derecha, y habríamos sido muy felices. Pero por mala suerte, no solo la memoria física tiene menos (24 aquí) unidades de memoria disponibles, tiene que ser compartido entre múltiples procesos también! 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 page contiene 8 ubicaciones, todo el espacio de direcciones virtuales de 40 ubicaciones contiene 5 páginas). Así que esta ubicación pertenece a la página no. 4 (35/8). Dentro de este page, esta ubicación tiene una compensación de 5 (35%8). Así que esta ubicación puede ser especificado por la tupla (pageIndex, offset) = (4,3). Esto es solo el comienzo, por lo que ninguna parte del proceso se almacena en la memoria física real todavía. Así que el page table, que mantiene un mapeo de las páginas de la izquierda a las páginas reales de la derecha (donde se llaman frames) actualmente está vacío. So 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 cuya las direcciones van desde 32 hasta 39). Cuando llega, OS asigna la página en algún lugar de la RAM, digamos el primer fotograma en sí, y el page table para este proceso toma nota de que page 4 se asigna a frame 0 en la RAM. Ahora los datos están finalmente allí en la memoria física. OS vuelve a consultar la tabla page para la tupla (4,3), y esta vez, la tabla page dice que page 4 ya está asignada a frame 0 en la RAM. Así OS simplemente va a la 0th marco en RAM, accede a los datos en offset 3 en ese marco (Tómese un momento para entender esto. Todo page, que fue traída desde el disco, es trasladado a frame. Así que cualquiera que sea el desplazamiento de una ubicación de memoria individual en una página era, será el mismo en el marco, ya que dentro de la page/frame, la unidad de memoria todavía 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 en sí, sino que para ser recuperado del disco para ser cargado en la memoria, constituye un miss .

Bien. Ahora supongamos que se hace un acceso a la memoria para location 28. Se reduce a (3,4). Page table ahora mismo solo tiene una entrada, mapeando page 4 a frame 0. Así que esto es otra vez un miss , el proceso renuncia a la CPU, el controlador del dispositivo obtiene la página del disco, el proceso recupera el control de la CPU de nuevo, y su page table se actualiza. Diga ahora la página 3 se asigna a frame 1 en la RAM. Así que (3,4) se convierte en (1,4), y los datos en esa ubicación en RAM se devuelven. Bien. De esta manera, supongamos que el siguiente acceso a la memoria es para la ubicación 8, que se traduce como (1,0). Page 1 no está en la memoria todavía, el mismo procedimiento se repite, y la page se asigna en frame 2 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 hasta. Supongamos que la siguiente solicitud de acceso a la memoria para este proceso es de address 30. Se asigna a (3,6), y page table dice que la página 3 está en RAM, y se asigna a frame 1. Yay! Por lo tanto, los datos se obtienen de la ubicación de la RAM (1,6) y se devuelven. Esto constituye un golpe , ya que los datos requeridos se pueden obtener directamente de la RAM, por lo que son muy rápidos. Del mismo modo, las próximas solicitudes de acceso, por ejemplo para ubicaciones 11, 32, 26, 27 todos son hits, es decir, los datos solicitados por el proceso se encuentran directamente en la RAM sin necesidad de buscar en otro lugar.

Ahora supongamos que viene una solicitud de acceso a la memoria para la ubicación 3. Se traduce como (0,3), y page table para este proceso, que actualmente tiene 3 entradas, para páginas 1, 3 y 4 dice que esta página no está en la memoria. Al igual que los casos anteriores, se obtiene desde el disco, sin embargo, a diferencia de los casos anteriores, la RAM se llena! Entonces, ¿qué hacer ahora? Aquí yace la belleza de lo virtual memoria, un marco de la RAM es desalojado! (Varios factores determinan qué marco debe ser desalojado. Puede ser LRU basado, donde el marco al que se accedió menos recientemente para un proceso debe ser desalojado. Puede ser first-cum-first-evicted la base, donde es desalojado el marco, que hace más tiempo se ha asignado, etc. Así que un marco es desalojado. Diga frame 1 (solo elegirlo al azar). Sin embargo, de que frame se asigna a algunos page! (Actualmente, está mapeado por la tabla de páginas de nuestro único proceso de page 4). Así que ese proceso tiene que ser contado esta trágica noticia, que uno frame, qué desafortunado le pertenece, es ser desalojado de RAM para hacer espacio para otro pages. El proceso tiene que asegurarse de que actualiza su page table con esta información, es decir, eliminar la entrada para ese dúo de marco de página, de modo que la próxima vez que se realice una solicitud para ese page, le dice al proceso que esto page ya no está en la memoria, y tiene que ser obtenido desde el disco. Bien. Así que frame 1 es desalojado, page 0 se introduce y se coloca allí en la RAM, y la entrada de page 4 se elimina y se reemplaza por page 0 asignando al mismo frame 1. Así que ahora nuestro mapeo se ve así (tenga en cuenta el cambio de color en el segundo frame en el lado derecho):

Vio lo que acaba de suceder? El proceso tenía que crecer, necesitaba más espacio que la RAM disponible, pero a diferencia de nuestro escenario anterior, donde cada proceso en la RAM tenía que moverse para acomodar un proceso en crecimiento, aquí sucedió solo por uno page ¡reemplazo! Esto fue posible por el hecho de que la memoria de un proceso ya no necesita ser contigua, puede residir en diferentes lugares en trozos, el sistema operativo mantiene la información sobre dónde están y, cuando es necesario, se consultan adecuadamente. Nota: usted podría estar pensando, eh, ¿qué pasa si la mayoría de las veces es un 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 sigue locality of reference, es decir, si se utilizan datos de alguna ubicación de memoria, los siguientes datos necesarios se ubicarán en algún lugar muy cercano, tal vez desde el mismo page, las page que se acaba de cargar en la memoria. Como resultado, la próxima falta sucederá después de bastante en algún momento, la mayoría de los próximos requisitos de memoria serán cumplidos por la página que acaba de ingresar, o las páginas que ya están en memoria que se usaron recientemente. El mismo principio exacto nos permite desalojar el menos recientemente utilizado page también, con la lógica de que lo que no se ha utilizado en un tiempo, no es probable que se utilice en un tiempo también. Sin embargo, no siempre es así, y en casos excepcionales, sí, el rendimiento puede sufrir. Más sobre esto más adelante.

Solución a Problema 4: Los procesos ahora pueden crecer fácilmente, si se enfrenta un problema de espacio, todo lo que requiere es hacer un simple reemplazo page, 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 utiliza como copia de seguridad, los nuevos datos necesarios se cargan en la memoria desde el disco y los datos menos utilizados 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 una ilusión de memoria ilimitada. Otra razón para el nombre Virtual Memory, te da ilusión de memoria que no está realmente disponible!

Genial. Anteriormente nos enfrentamos a un problema en el que a pesar de que un proceso se reduce en 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 en tamaño, muchos de su pages ya no se utilizan, por lo que cuando otros procesos necesitan más memoria, un simple LRU el desalojo basado desaloja automáticamente a los menos utilizados pages de RAM, y las reemplaza con las nuevas páginas de los otros procesos (y por supuesto actualizando el page tables de todos estos procesos, así como el proceso original que ahora requiere menos espacio), todos estos sin ninguna operación de compactación costosa!

Solución a Problema 3: Cada vez que los procesos se reducen de tamaño, su frames en RAM será menos utilizado, por lo que un simple desalojo basado en LRU puede desalojar esas páginas y reemplazarlas con pages requerido por nuevos procesos, evitando así Internal Fragmentation sin necesidad de compaction.

En cuanto al problema 2, tómese un momento para entender esto, ¡el escenario en sí está completamente eliminado! No hay necesidad de mover un proceso para acomodar un nuevo proceso, porque ahora todo el proceso nunca necesita encajar a la vez, solo ciertas páginas de la misma tienen que encajar ad hoc, que sucede al desalojar frames de RAM. Todo sucede en unidades de pages, por lo tanto no hay concepto de hole ahora, y por lo tanto no hay cuestión de nada en movimiento! Puede ser 10 pages tuvo que ser trasladado a causa de este nuevo requisito, hay miles de pages que se dejan intactos. Mientras que, antes, todos los procesos (cada bit de ellos) tenían que ser movidos!

Solución al problema 2: Para dar cabida a un nuevo proceso, los datos de las partes menos utilizadas recientemente de otros procesos tienen que ser desalojados según sea necesario, y esto sucede 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 hacer alguna operación de E/S, ¡puede renunciar a la CPU fácilmente! OS simplemente desaloja a todos sus pages desde la RAM (tal vez almacenarlo en algún caché) mientras que nuevo los procesos ocupan la RAM mientras tanto. Cuando se realiza la operación de E/S, el sistema operativo simplemente restaura pages a la RAM (por supuesto, mediante la sustitución de la 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 ahora, y por lo tanto pueden renunciar a la memoria!)

Solución al problema 5: Cuando un proceso está realizando operaciones de E/S, puede renunciar fácilmente al uso de RAM, lo que puede ser utilizado por otros procesos. Esto conduce a la utilización adecuada de la RAM.

Y por supuesto, ahora ningún proceso está accediendo a la RAM directamente. Cada proceso está accediendo a una ubicación de memoria virtual, que se asigna a una dirección RAM física y es mantenida por el page-table de ese proceso. La asignación está respaldada por el sistema operativo, el sistema operativo le permite al proceso saber qué marco está vacío para que se pueda colocar una nueva página para un proceso allí. Dado que esta asignación de memoria es supervisada por el sistema operativo en sí mismo, puede garantizar fácilmente que ningún proceso invada el contenido de otro proceso asignando solo fotogramas 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 toda la asignación es administrada por el propio sistema operativo, y cada proceso se ejecuta en su propio espacio de direcciones virtuales en caja de arena.

So paging (entre otras técnicas), junto con la memoria virtual, es lo que alimenta los softwares de hoy en día que se ejecutan en OS-es! 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 a prueba de todo. Hay defectos:

1. Paging es, en última instancia, dar al usuario la ilusión de memoria infinita mediante el uso de disco como copia de seguridad secundaria. Recuperar datos del almacenamiento secundario para que quepan en la memoria (llamado page swap, y el evento de no encontrar la página deseada en RAM se llama page fault) es caro ya que es una operación IO. Esto ralentiza el proceso. Varios de estos cambios de página ocurren en sucesión, y el proceso se vuelve dolorosamente lento. Visto su el software se ejecuta bien y dandy, y de repente se vuelve tan lento que casi se cuelga, o te deja sin opción de reiniciarlo? Posiblemente estaban sucediendo demasiados intercambios de páginas, lo que lo hacía lento (llamado thrashing).

¿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 corrompen sus datos, incluso cuando se ejecuta 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 Paginación. 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 ninguna parte per se, es una abstracción, siempre presente, cuando se inicia el software/proceso/programa, se crea una nueva tabla de páginas para ella, y contiene la asignación 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 un sentido, son, en realidad, lo que se puede decir, the virtual memory.

Quién se encarga de la memoria virtual y cuál es el tamaño de la memoria virtual? - Es atendido por, en tándem, el sistema operativo y el software. Imagine una función en su código (que finalmente se compiló y se convirtió en el ejecutable que generó el proceso) que contiene una variable local: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 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 en la dirección física real para 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 de i en una dirección física real, de modo que siempre, dentro de esa función, algún código requiere el valor de i, ese proceso puede consultar el sistema operativo para esa dirección virtual, y el sistema operativo a su vez puede consultar el dirección física para el valor almacenado, y devolverlo.

Supongamos 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 Ventanas de 32 bits, es 16 TB, en ventanas de 64 bits, es 256 TB. Por supuesto, también está limitado por el tamaño del disco, ya que es donde se realiza la copia de seguridad de la memoria.

Estoy copiando descaradamente los extractos de la página man de top

VIRT Image Imagen virtual (kb) La cantidad total de memoria virtual utilizada por la tarea. Incluye todo el código, los datos y las bibliotecas compartidas, además de las páginas que han sido intercambiado y páginas que han sido mapeadas pero no utilizadas.

SWAP size Tamaño intercambiado (kb) Memoria que no es residente pero que está presente en una tarea. Esta es la memoria que ha sido intercambiada, pero podría incluir no adicionales- memoria de residentes. Esta columna se calcula restando la memoria física de la memoria virtual

Ver aquí: Memoria Física Vs Virtual

La memoria virtual se almacena en el disco duro y se usa cuando se llena la RAM. La memoria física está limitada al tamaño de los chips RAM instalados en el ordenador. La memoria virtual está limitada por el tamaño del disco duro, por lo que la memoria virtual tiene la capacidad de más almacenamiento.