Articulo de referencia

Gestión de memoria basada en regiones

En informática , la gestión de memoria basada en regiones es un tipo de gestión de memoria en la que cada objeto asignado se asigna a una región . Una región, también llamada pa...

En informática , la gestión de memoria basada en regiones es un tipo de gestión de memoria en la que cada objeto asignado se asigna a una región . Una región, también llamada partición , subgrupo , zona , área o contexto de memoria , es una colección de objetos asignados que pueden reasignarse o liberarse de forma eficiente de una sola vez. Los asignadores de memoria que utilizan la gestión basada en regiones suelen denominarse asignadores de área , y cuando funcionan simplemente "incrementando" un único puntero, se denominan asignadores de incremento .

Al igual que la asignación en la pila , las regiones facilitan la asignación y liberación de memoria con una sobrecarga mínima; sin embargo, son más flexibles, permitiendo que los objetos tengan una vida útil mayor que la del marco de pila en el que fueron asignados. En las implementaciones típicas, todos los objetos de una región se asignan en un único rango contiguo de direcciones de memoria, de forma similar a como se asignan los marcos de pila.

En OS/360 y sus sucesores , el concepto se aplica en dos niveles; cada trabajo se ejecuta dentro de una partición [ a ] o región contigua. [ b ] Las solicitudes de asignación de almacenamiento especifican un subgrupo, y la aplicación puede liberar un subgrupo completo. El almacenamiento para un subgrupo se asigna desde la región o partición en bloques que son múltiplos de 2 KiB [ c ] o 4 KiB [ d ] que generalmente no son contiguos.

Ejemplo

Como ejemplo sencillo, considere el siguiente código C++ , que implementa un entorno de compilación simple y un tipo de dato simple que consta de una cadena y un valor entero.

importar std ;using std :: bad_alloc ; using std :: construcible_from ; using std :: span ; using std :: string ; using std :: unique_ptr ;clase Arena { privado : unique_ptr < byte [] > almacenamiento ; tamaño_t capacidad ; tamaño_t desplazamiento ;constexpr void * allocateBytes ( size_t size , size_t alignment ) { void * ptr = storage . get () + offset ; size_t space = capacity - offset ; size_t alignedOffset = capacity - space ; if ( alignedOffset + size > capacity ) { throw bad_alloc ( "¡Error al asignar bytes!" ); } offset = alignedOffset + size ; return ptr ; } public : constexpr explicit Arena ( size_t capacity ) : storage { std :: make_unique < byte [] > ( capacity )}, capacity { capacity }, offset { 0 } {}constexpr ~ Arena () = default ; constexpr Arena ( Arena && ) noexcept = default ; constexpr Arena & operator = ( Arena && ) noexcept = default ;constexpr Arena ( const Arena & ) = delete ( "Copiar la construcción de Arena está deshabilitada" ); constexpr Arena & operator = ( const Arena & ) = delete ( "Copiar la asignación de Arena está deshabilitada" );template < typename T , typename ... Args > requiere constructible_from < T , Args ... > constexpr T * allocate ( Args && ... args ) { void * mem = allocateBytes ( sizeof ( T ), alignof ( T )); return std :: construct_at ( static_cast < T *> ( mem ), std :: forward < Args > ( args )...); }constexpr void reset () noexcept { offset = 0 ; }constexpr span < byte > remaining () const noexcept { return { storage . get () + offset , capacity - offset }; } };struct Nodo { string nombre ; int valor ; };int main () { Arena arena ( 4096 ); Node * a = arena . allocate < Node > ( "Alpha" , 1 ); Node * b = arena . allocate < Node > ( "Beta" , 2 );std :: println ( "a = ({}, {})" , a- > name , a- > value ); std :: println ( "b = ({}, {})" , b- > name , b- > value ) ; arena.reset ( ); }

Implementación

Las regiones explícitas simples son fáciles de implementar; la siguiente descripción se basa en el trabajo de Hanson. [ 1 ] Cada región se implementa como una lista enlazada de grandes bloques de memoria; cada bloque debe ser lo suficientemente grande como para servir para muchas asignaciones. El bloque actual mantiene un puntero a la siguiente posición libre en el bloque, y si el bloque está lleno, se asigna uno nuevo y se agrega a la lista. Cuando se desasigna la región, el puntero a la siguiente posición libre se restablece al inicio del primer bloque, y la lista de bloques se puede reutilizar para la siguiente región asignada. Alternativamente, cuando se desasigna una región, su lista de bloques se puede agregar a una lista global de bloques libres desde la cual otras regiones pueden asignar nuevos bloques posteriormente. Con cualquiera de los casos de este esquema simple, no es posible desasignar objetos individuales en las regiones.

El coste total por byte asignado en este esquema es muy bajo; casi todas las asignaciones implican únicamente una comparación y una actualización del puntero a la siguiente posición libre. La desasignación de una región es una operación de tiempo constante y se realiza con poca frecuencia. A diferencia de los sistemas típicos de recolección de basura , no es necesario etiquetar los datos con su tipo.

Historia y conceptos

El concepto básico de regiones es muy antiguo, apareció por primera vez en 1967 en el paquete de almacenamiento gratuito AED de Douglas T. Ross, en el que la memoria se dividió en una jerarquía de zonas; cada zona tenía su propio asignador, y una zona podía liberarse de una sola vez, lo que hacía que las zonas fueran utilizables como regiones. [ 2 ] En 1976, el estándar PL/I incluyó el tipo de datos AREA. [ 3 ] En 1990, Hanson demostró que las regiones explícitas en C (que él llamó arenas ) podían lograr un rendimiento de tiempo por byte asignado superior incluso al mecanismo de asignación de montón más rápido conocido. [ 1 ] Las regiones explícitas fueron fundamentales en el diseño de algunos de los primeros proyectos de software basados ​​en C, incluido el servidor HTTP Apache , que las llama grupos, y el sistema de gestión de bases de datos PostgreSQL , que las llama contextos de memoria. [ 4 ] Al igual que la asignación de montón tradicional, estos esquemas no proporcionan seguridad de memoria ; Es posible que un programador acceda a una región después de que se haya liberado mediante un puntero colgante , o que olvide liberar una región, lo que provoca una fuga de memoria .

inferencia de región

En 1988, los investigadores comenzaron a estudiar cómo utilizar regiones para una asignación segura de memoria, introduciendo el concepto de inferencia de regiones . En este concepto, el compilador inserta la creación y liberación de regiones, así como la asignación de expresiones de asignación estática individuales a regiones específicas, durante la compilación. El compilador puede realizar esta operación de tal manera que garantiza que no se produzcan punteros colgantes ni fugas de memoria.

En un trabajo anterior de Ruggieri y Murtagh, [ 5 ] se crea una región al comienzo de cada función y se libera al final. Luego utilizan el análisis de flujo de datos para determinar la vida útil de cada expresión de asignación estática y la asignan a la región más joven que contiene toda su vida útil.

En 1994, este trabajo fue generalizado en un trabajo fundamental de Tofte y Talpin para admitir el polimorfismo de tipos y funciones de orden superior en Standard ML , un lenguaje de programación funcional , utilizando un algoritmo diferente basado en la inferencia de tipos y los conceptos teóricos de tipos de región polimórficos y el cálculo de regiones . [ 6 ] [ 7 ] Su trabajo introdujo una extensión del cálculo lambda que incluye regiones, agregando dos construcciones:

mi1{\displaystyle e_{1}}enρ{\displaystyle \rho }: Calcula el resultado de la expresiónmi1{\displaystyle e_{1}}y almacenarlo en la regiónρ{\displaystyle \rho };
región de la muerteρ{\displaystyle \rho }enmi2{\displaystyle e_{2}}fin: Crea una región y vincúlala aρ{\displaystyle \rho }; evaluarmi2{\displaystyle e_{2}}; luego, desasignar la región.

Debido a esta estructura sintáctica, las regiones están anidadas , lo que significa que sir2{\displaystyle r_{2}}se crea despuésr1{\displaystyle r_{1}}, también debe ser desasignado antesr1{\displaystyle r_{1}}; el resultado es una pila de regiones. Además, las regiones deben ser desasignadas en la misma función en la que se crean. Estas restricciones fueron flexibilizadas por Aiken et al. [ 8 ] .

Este cálculo lambda extendido tenía como objetivo servir como una representación intermedia con seguridad de memoria demostrable para compilar programas ML estándar a código máquina, pero la creación de un traductor que produjera buenos resultados en programas grandes se enfrentó a una serie de limitaciones prácticas que tuvieron que resolverse con nuevos análisis, incluyendo el manejo de llamadas recursivas, llamadas de cola y la eliminación de regiones que contenían un solo valor. Este trabajo se completó en 1995 [ 9 ] y se integró en ML Kit, una versión de ML basada en la asignación de regiones en lugar de la recolección de basura. Esto permitió una comparación directa entre ambos en programas de prueba de tamaño mediano, obteniendo resultados muy variables ("entre 10 veces más rápido y cuatro veces más lento") dependiendo de cuán "amigable con las regiones" era el programa; sin embargo, los tiempos de compilación eran del orden de minutos. [ 10 ] ML Kit finalmente se escaló a grandes aplicaciones con dos adiciones: un esquema para la compilación separada de módulos y una técnica híbrida que combina la inferencia de regiones con la recolección de basura de rastreo. [ 11 ] [ 12 ]

Generalización a nuevos entornos lingüísticos

Tras el desarrollo de ML Kit, las regiones comenzaron a generalizarse a otros entornos lingüísticos:

  • Diversas extensiones del lenguaje de programación C:
    • El dialecto seguro de C Cyclone , que entre muchas otras características añade soporte para regiones explícitas, y evalúa el impacto de migrar aplicaciones C existentes para utilizarlas. [ 13 ] [ 14 ] [ 15 ]
    • Se implementó una extensión de C llamada RC [ 16 ] que utiliza regiones gestionadas explícitamente, pero también utiliza el conteo de referencias en las regiones para garantizar la seguridad de la memoria al asegurar que ninguna región se libere prematuramente. [ 17 ] [ 18 ] Las regiones reducen la sobrecarga del conteo de referencias, ya que las referencias internas a las regiones no requieren que se actualicen los conteos cuando se modifican. RC incluye un sistema de tipos estático explícito para las regiones que permite eliminar algunas actualizaciones del conteo de referencias. [ 19 ]
    • Una restricción de C llamada Control-C limita los programas a usar regiones (y solo una región a la vez), como parte de su diseño para garantizar estáticamente la seguridad de la memoria. [ 20 ]
  • Las regiones se implementaron para un subconjunto de Java , [ 21 ] y se convirtieron en un componente crítico de la gestión de memoria en Java en tiempo real , que las combina con tipos de propiedad para demostrar la encapsulación de objetos y eliminar las comprobaciones en tiempo de ejecución sobre la desasignación de regiones. [ 22 ] [ 23 ] [ 24 ] Más recientemente, se propuso un sistema semiautomático para inferir regiones en aplicaciones Java embebidas en tiempo real, que combina un análisis estático en tiempo de compilación, una política de asignación de regiones en tiempo de ejecución y sugerencias del programador. [ 25 ] [ 26 ] Las regiones son adecuadas para la computación en tiempo real porque su sobrecarga de tiempo es estáticamente predecible, sin la complejidad de la recolección de basura incremental.
  • Se implementaron para los lenguajes de programación lógica Prolog [ 27 ] [ 28 ] y Mercury [ 29 ] [ 30 ] extendiendo el modelo de inferencia de región de Tofte y Talpin para admitir retroceso y cortes.
  • La gestión de almacenamiento basada en regiones se utiliza en todo el lenguaje de programación paralela ParaSail . Debido a la falta de punteros explícitos en ParaSail, [ 31 ] no hay necesidad de conteo de referencias.

Soporte de biblioteca estándar

  • Características de C++ std::pmr::monotonic_buffer_resourcedentro de la std::pmrbiblioteca (definidas en el encabezado <memory_resource>). [ 32 ]
  • Java 21 añadió una API de Java para asignar y liberar Arenas. [ 33 ] El propósito declarado de estas es mejorar la integración segura con bibliotecas nativas para prevenir fugas de memoria de la JVM y reducir el riesgo de corrupción de memoria de la JVM por código nativo. [ 34 ] Las Arenas son parte de la Interfaz de Memoria y Funciones Extranjeras de Java (que se introdujo en Java 22 y se estabilizó en Java 25), que es sucesora de la Interfaz Nativa de Java (JNI), e incluye clases como java.lang.foreign.Arena, java.lang.foreign.MemorySegment, y otras. [ 35 ]
  • Go cuenta con una arenabiblioteca, con arena.Arena. [ 36 ]
  • Zig tiene la std.heap.ArenaAllocatorestructura. [ 37 ]

Desventajas

Los sistemas que utilizan regiones pueden experimentar problemas cuando las regiones se vuelven muy grandes antes de ser liberadas y contienen una gran proporción de datos obsoletos; estos se conocen comúnmente como "fugas" (aunque finalmente se liberan). Eliminar las fugas puede implicar reestructurar el programa, generalmente introduciendo nuevas regiones de vida útil más corta. Depurar este tipo de problema es especialmente difícil en sistemas que utilizan inferencia de regiones, donde el programador debe comprender el algoritmo de inferencia subyacente o examinar la representación intermedia detallada para diagnosticar el problema. Los recolectores de basura de rastreo son más eficaces para liberar este tipo de datos de manera oportuna sin cambios en el programa; esta fue una justificación para los sistemas híbridos de regiones/recolectores de basura. [ 11 ] Por otro lado, los recolectores de basura de rastreo también pueden presentar fugas sutiles si se retienen referencias a datos que nunca se volverán a utilizar.

La gestión de memoria basada en regiones funciona mejor cuando el número de regiones es relativamente pequeño y cada una contiene muchos objetos; los programas que contienen muchas regiones dispersas presentarán fragmentación interna , lo que conlleva un desperdicio de memoria y una sobrecarga de tiempo en la gestión de regiones. Nuevamente, en presencia de inferencia de regiones, este problema puede ser más difícil de diagnosticar.

métodos híbridos

Como se mencionó anteriormente, RC utiliza un híbrido de regiones y conteo de referencias , lo que limita la sobrecarga del conteo de referencias, ya que las referencias internas a las regiones no requieren que se actualicen los conteos cuando se modifican. De manera similar, algunos métodos híbridos de marcado y región combinan la recolección de basura de rastreo con regiones; estos funcionan dividiendo el montón en regiones, realizando una pasada de marcado y barrido en la que se marcan las regiones que contienen objetos activos y luego liberando las regiones no marcadas. Estos requieren una desfragmentación continua para seguir siendo efectivos. [ 38 ]

Notas

  1. Para MFT y OS/VS1
  2. Para MVT , OS/VS2 y sistemas MVS posteriores .
  3. Para OS/360 y OS/VS1
  4. Para sistemas OS/VS2 y MVS posteriores.

Referencias

  1. 1 2 Hanson, David R. (1989). "Asignación y desasignación rápida de memoria basada en la duración de los objetos" . Software: Practice and Experience . 20 (1): 5– 12. doi : 10.1002/spe.4380200104 . S2CID 8960945 . {{cite journal}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  2. Ross, Douglas (1967). "El paquete de almacenamiento gratuito de DEA" . Communications of the ACM . 10 (8): 481– 492. doi : 10.1145/363534.363546 . S2CID 6572689 . 
  3. Instituto Nacional Estadounidense de Estándares, Inc. (1976). Lenguaje de programación estándar nacional estadounidense PL/I .
  4. 2010 PostgreSQL Global Development Group (1996). "Sección 41.3: Gestión de memoria" . Documentación de PostgreSQL 8.2.15 . Consultado el 22 de febrero de 2010 .{{cite web}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  5. Ruggieri, Cristina; Murtagh, Thomas P. (1988). "Análisis del ciclo de vida de objetos asignados dinámicamente" . POPL '88: Actas del 15.º simposio ACM SIGPLAN-SIGACT sobre principios de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. doi : 10.1145/73560.73585 . Consultado el 22 de febrero de 2010 .
  6. Tofte, Mads; Jean-Pierre Talpin (1993). Una teoría de la asignación de pila en lenguajes de tipado polimórfico (Informe técnico). Departamento de Informática, Universidad de Copenhague. 93/15.En Citeseer
  7. Tofte, Mads ; Talpin, Jean-Pierre (1994). "Implementación del cálculo λ por valor tipado mediante una pila de regiones" . POPL '94: Actas del 21.º simposio ACM SIGPLAN-SIGACT sobre principios de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. págs. 188-201 . doi : 10.1145/174675.177855 . ISBN  0-89791-636-0Consultado el 15 de abril de 2014 .
  8. Aiken, Alex; Manuel Fähndrich, Raph Levien (1995). Mejor gestión de la memoria estática: Mejora del análisis basado en regiones de lenguajes de orden superior (Informe técnico). Departamento de EECS, Universidad de California, Berkeley. UCB/CSD-95-866.En Citeseer
  9. Birkedal, Lars ; Tofte, Mads ; Vejlstrup, Magnus (1996). "De la inferencia de regiones a las máquinas de von Neumann mediante la inferencia de representación de regiones" . POPL '96: Actas del 23.er simposio ACM SIGPLAN-SIGACT sobre principios de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. págs. 171–183 . doi : 10.1145/237721.237771 . ISBN  0-89791-769-3. Consultado el 22 de febrero de 2010 .
  10. Tofte, Mads; Birkedal, Lars; Elsman, Martin; Hallenberg, Niels (2004). "Una retrospectiva sobre la gestión de memoria basada en regiones" . Higher Order Symbolic Computing . 17 (3): 245– 265. doi : 10.1023/B:LISP.0000029446.78563.a4 . ISSN 1388-3690 . 
  11. ^ Hallenberg , Niels; Elsman, Martín; Tofte, Mads (2003). "Combinación de inferencia regional y recolección de basura". Avisos SIGPLAN . 37 (5): 141– 152. doi : 10.1145/543552.512547 . ISSN 0362-1340 . 
  12. Elsman, Martin (2003). "Seguridad de la recolección de basura para la administración de memoria basada en regiones". SIGPLAN Notices . 38 (3): 123– 134. CiteSeerX 10.1.1.57.8914 . doi : 10.1145/640136.604190 . ISSN 0362-1340 .  
  13. "Cyclone: ​​Introducción a las regiones" . Manual de usuario de Cyclone . Consultado el 22 de febrero de 2010 .
  14. Grossman, Dan; Morrisett, Greg; Jim, Trevor; Hicks, Michael; Wang, Yanling (2002). "Gestión de memoria basada en regiones en Cyclone". SIGPLAN Notices . 37 (5): 282– 293. doi : 10.1145/543552.512563 .
  15. Hicks, Michael; Morrisett, Greg ; Grossman, Dan (2004). "Experiencia con la gestión segura de la memoria manual en Cyclone" . ISMM '04: Actas del 4.º simposio internacional sobre gestión de la memoria . Nueva York, NY, EE. UU.: ACM. págs. 73–84 . doi : 10.1145/1029873.1029883 . ISBN  1-58113-945-4. Consultado el 22 de febrero de 2010 .
  16. Gay, David (1999). "RC - Gestión de memoria segura basada en regiones para C" . Página web de David Gay . Intel Labs Berkeley. Archivado del original el 26 de febrero de 2009. Consultado el 22 de febrero de 2010 .
  17. Gay, David ; Aiken, Alex (1998). "Gestión de memoria con regiones explícitas" . PLDI '98: Actas de la conferencia ACM SIGPLAN 1998 sobre diseño e implementación de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. págs. 313–323 . doi : 10.1145/277650.277748 . ISBN  0-89791-987-4. Consultado el 22 de febrero de 2010 .
  18. Gay, David Edward (2001). Gestión de memoria con regiones explícitas (PDF) (tesis doctoral en Ciencias de la Computación). Universidad de California en Berkeley . Recuperado el 20 de febrero de 2010 .
  19. Gay, David ; Aiken, Alex (2001). "Soporte lingüístico para regiones". SIGPLAN Notices . 36 (5): 70– 80. CiteSeerX 10.1.1.650.721 . doi : 10.1145/381694.378815 . ISSN 0362-1340 .  
  20. Kowshik, Sumant; Dhurjati, Dinakar; Adve, Vikram (2002). "Garantizar la seguridad del código sin comprobaciones en tiempo de ejecución para sistemas de control en tiempo real" . CASES '02: Actas de la conferencia internacional de 2002 sobre compiladores, arquitectura y síntesis para sistemas embebidos . Nueva York, NY, EE. UU.: ACM. págs. 288–297 . doi : 10.1145/581630.581678 . ISBN  1-58113-575-0. Consultado el 22 de febrero de 2010 .
  21. Christiansen, Morten V. (1998). "Gestión de memoria basada en regiones en Java" . Departamento de Ciencias de la Computación (DIKU), Universidad de Copenhague ( FTP ) . Recuperado el 20 de febrero de 2010 .(Para ver los documentos, consulte Ayuda:FTP )
  22. Beebee, William S.; Rinard, Martin C. (2001). "Una implementación de memoria con ámbito para Java en tiempo real" . EMSOFT '01: Actas del Primer Taller Internacional sobre Software Embebido . Londres, Reino Unido: Springer-Verlag. págs. 289–305 . ISBN  3-540-42673-6. Consultado el 22 de febrero de 2010 .
  23. Sălcianu, Alexandru; Chandrasekhar Boyapati, William Beebee, Jr., Martin Rinard (2003). Un sistema de tipos para la gestión segura de memoria basada en regiones en Java en tiempo real (PDF) (Informe técnico). Laboratorio de Ciencias de la Computación del MIT. MIT-LCS-TR-869.{{cite tech report}}: CS1 maint: varios nombres: lista de autores ( enlace )
  24. Boyapati, Chandrasekhar ; Salcianu, Alexandru ; Beebee, William Jr. (2003). "Tipos de propiedad para una gestión segura de memoria basada en regiones en Java en tiempo real" . PLDI '03: Actas de la conferencia ACM SIGPLAN 2003 sobre diseño e implementación de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. págs. 324–337 . doi : 10.1145/781131.781168 . ISBN  1-58113-662-5. Consultado el 22 de febrero de 2010 .
  25. Nahkli, Chaker ; Rippert, Christophe ; Salagnac, Guillaume ; Yovine, Sergio (2007). "Gestión eficiente de memoria basada en regiones para sistemas embebidos en tiempo real con recursos limitados" (PDF) . Actas del "Taller sobre implementación, compilación y optimización de lenguajes, programas y sistemas orientados a objetos (ICOOOLPS'2006)" . Consultado el 22 de febrero de 2010 .
  26. Salagnac, Guillaume ; Rippert, Christophe (2007). «Gestión de memoria semiautomática basada en regiones para sistemas embebidos Java en tiempo real». RTCSA '07: Actas de la 13.ª Conferencia Internacional IEEE sobre Sistemas y Aplicaciones de Computación Embebida y en Tiempo Real . Washington, DC, EE. UU.: IEEE Computer Society. págs. 73–80 . doi : 10.1109/RTCSA.2007.67 . ISBN  978-0-7695-2975-2.
  27. Makholm, Henning (2000). Gestión de memoria basada en regiones en Prolog (PDF) (tesis de maestría en informática). Universidad de Copenhague, Dinamarca. Archivado del original (PDF) el 5 de junio de 2011. Recuperado el 20 de febrero de 2010 .
  28. Makholm, Henning (2000). "Un gestor de memoria basado en regiones para Prolog" . ISMM '00: Actas del 2.º simposio internacional sobre gestión de memoria . Nueva York, NY, EE. UU.: ACM. págs. 25-34 . doi : 10.1145/362422.362434 . ISBN  1-58113-263-8. Consultado el 22 de febrero de 2010 .
  29. Phan, Quan ; Janssens, Gerda (2007). Programación lógica . Lecture Notes in Computer Science. Vol. 4670/2007. Springer Berlin / Heidelberg. pp. 317–332 . doi : 10.1007/978-3-540-74610-2 . ISBN   978-3-540-74608-9ISSN 1611-3349 
  30. Phan, Quan ; Somogyi, Zoltan (2008). "Soporte en tiempo de ejecución para la gestión de memoria basada en regiones en Mercury" . ISMM '08: Actas del 7.º simposio internacional sobre gestión de memoria . Nueva York, NY, EE. UU.: ACM. págs. 61–70 . doi : 10.1145/1375634.1375644 . ISBN  978-1-60558-134-7Consultado el 15 de abril de 2014 .
  31. Taft, Tucker (2012). "Un camino sin punteros hacia la programación paralela orientada a objetos" . Blog de ParaSail . Consultado el 14 de septiembre de 2012 .
  32. cppreference.com (7 de marzo de 2026). "std::pmr::monotonic_buffer_resource" . cppreference.com . cppreference.com.
  33. "Segmentos y áreas de memoria" . Oracle.
  34. Cimadamore, Maurizio. "JEP 454: API de funciones y memoria externas" . OpenJDK.
  35. "Paquete java.lang.foreign" . Oracle Corporation.
  36. Lenguaje de programación Go. "Área de comandos" . go.dev . Lenguaje de programación Go . Consultado el 8 de marzo de 2026 .
  37. Lenguaje de programación Zig. "std.heap.ArenaAllocator" . ziglang.org . Lenguaje de programación Zig . Consultado el 8 de marzo de 2026 .
  38. Blackburn, Stephen M .; McKinley, Kathryn S. (2008). "Immix: un recolector de basura de región de marcado con eficiencia espacial, recolección rápida y rendimiento de mutador" . PLDI '08: Actas de la conferencia ACM SIGPLAN de 2008 sobre diseño e implementación de lenguajes de programación . Nueva York, NY, EE. UU.: ACM. págs. 22–32 . doi : 10.1145/1375581.1375586 . ISBN  978-1-59593-860-2Consultado el 15 de abril de 2014 .
Obtenido de " https://en.wikipedia.org/w/index.php?title=Region-based_memory_management&oldid=1349813472 "