Region-based memory management: Difference between revisions

Revision as of 15:21, 7 July 2025

Latest revision as of 04:16, 15 August 2025

(12 intermediate revisions by 3 users not shown)

Line 6:

Like [[stack allocation]], regions facilitate allocation and deallocation of memory with low overhead; but they are more flexible, allowing objects to live longer than the [[stack frame]] in which they were allocated. In typical implementations, all objects in a region are allocated in a single contiguous range of memory addresses, similarly to how stack frames are typically allocated.

In [[OS/360 and successors]], the concept applies at two levels; each job runs within a contiguous partition{{efn|For [[OS/360 and successors#MFT|MFT]] and [[OS/VS1]]}} or region.{{efn|For [[OS/360 and successors#MVT|MVT]], [[OS/VS2]] and later [[MVS]] systems.}} Storage allocation requests specify a subpool, and the application can free an entire subpool. Storage for a subpool is allocated from the region or partition in blocks that are a multiple of 2 KibKiB{{efn|For OS/360 and OS/VS1}} or 4 KiB{{efn|For OS/VS2 and later MVS systems.}} that generally are not contiguous.

== Example ==

As a simple example, consider the following [[C++]] code which allocates and then deallocates a [[linked list]] data structure:

<syntaxhighlight lang="cpp">

class Region;

struct ListNode {

ListNode* next;

ListNode(Region* region):

next{nullptr} {}

};

Region* r = new Region();

ListNode* head = nullptr;

for (int i = 1; i <= 1000; ++i) {

ListNode* newNode = new ListNode(r);

newNode->next = head;

head = newNode;

}

// ...

// (use list here)

// ...

delete r;

</syntaxhighlight>

Although it required many operations to construct the linked list, it can be quickly deallocated in a single operation by destroying the region in which the nodes were allocated. There is no need to traverse the list.

== Implementation ==

Line 111 ⟶ 85:

{{cite conference |title=Semi-Automatic Region-Based Memory Management for Real-Time Java Embedded Systems |last1=Salagnac |first1=Guillaume |author-link1=Guillaume Salagnac|last2=Rippert |first2=Christophe |author-link2=Christophe Rippert|year=2007 |publisher=IEEE Computer Society |___location=Washington, DC, USA |book-title=RTCSA '07: Proceedings of the 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications |pages=73&ndash;80 |isbn=978-0-7695-2975-2|doi=10.1109/RTCSA.2007.67}}

</ref> Regions are a good fit for [[real-time computing]] because their time overhead is statically predictable, without the complexity of incremental garbage collection.

* Java 21 added a Java API to allocate and release Arenas.<ref>{{cite web |title=Memory Segments and Arenas |url=https://docs.oracle.com/en/java/javase/21/core/memory-segments-and-arenas.html#GUID-01CE34E8-7BCB-4540-92C4-E127C1F62711 |publisher=Oracle}}</ref> The stated purpose of these is to improve safe integration with native libraries so as to prevent JVM memory leaks and to reduce the risk of JVM memory corruption by native code.<ref>{{cite web |last1=Cimadamore |first1=Maurizio |title=JEP 454: Foreign Function & Memory API |url=https://openjdk.org/jeps/454 |publisher=OpenJDK}}</ref> Arenas are a part of the Java Foreign Function and Memory Interface, which is a successor to [[Java Native Interface]] (JNI), and includes classes like <code>Arena</code>, <code>MemorySegment</code>, and others.<ref>{{cite web|title=Package java.lang.foreign|url=https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/package-summary.html|publisher=Oracle Corporation}}</ref>

<ref>{{cite web |last1=Cimadamore |first1=Maurizio |title=JEP 454: Foreign Function & Memory API |url=https://openjdk.org/jeps/454 |publisher=OpenJDK}}</ref>

* They were implemented for the [[logic programming]] languages [[Prolog]]<ref>

{{Cite thesis |degree=Masters in Computer Science |title=Region-based memory management in Prolog |url=http://www.diku.dk/OLD/publikationer/tekniske.rapporter/rapporter/00-09.pdf |last=Makholm |first=Henning |year=2000 |publisher=University of Copenhagen, Denmark |accessdate=20 February 2010 |url-status=dead |archive-url=https://web.archive.org/web/20110605004034/http://www.diku.dk/OLD/publikationer/tekniske.rapporter/rapporter/00-09.pdf |archive-date=5 June 2011 }}

Line 123 ⟶ 96:

</ref> by extending Tofte and Talpin's region inference model to support backtracking and cuts.

* Region-based storage management is used throughout the [[parallel programming language]] [[ParaSail (programming language)|ParaSail]]. Due to the lack of explicit pointers in ParaSail,<ref>

{{Cite web |url=httphttps://parasail-programming-language.blogspot.com/2012/08/a-pointer-free-path-to-object-oriented.html|title=A Pointer-Free path to Object Oriented Parallel Programming |last1=Taft |first1=Tucker |year=2012 |work=ParaSail blog |accessdate=14 September 2012}}</ref> there is no need for reference counting.

== Disadvantages ==