From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,93211508cf0a6c34,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.volia.net!news-out.ntli.net!newsrout1-gui.ntli.net!ntli.net!newspeer1-win.ntli.net!newsfe3-gui.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Memory Mapped Storage Pools. User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 25 Oct 2005 00:26:31 GMT NNTP-Posting-Host: 80.4.127.115 X-Complaints-To: http://www.ntlworld.com/netreport X-Trace: newsfe3-gui.ntli.net 1130199991 80.4.127.115 (Tue, 25 Oct 2005 01:26:31 BST) NNTP-Posting-Date: Tue, 25 Oct 2005 01:26:31 BST Organization: ntl Cablemodem News Service Xref: g2news1.google.com comp.lang.ada:5915 Date: 2005-10-25T00:26:31+00:00 List-Id: On Wed, 26 Oct 2005 20:08:44 -0400, Freejack wrote: > Ada Storage Pools, in Unix/Posix type environments, are typically > handled via the omnipresent C malloc() routine. While this undoubtedly > simplifies compiler/runtime development, it has left me desiring a > mechanism with a bit more control. > > So I've begun working on a library that allocates storage pools through > the lower level mmap() suite of system utilities. I'm tentatively calling > it Custom_Storage.Mapped_Pools > > It's intended use is for very large allocations that are intended to be > returned to the system upon finalization, rather than having the extra > memory linger in the program's process "space". I did this once, a few years ago. The objective were: 1) Allow region-based allocation (zero space overhead!) 2) Allow conventional "malloc/free" style allocation within each pool 3) task compatible ("thread safe") 4) Able to reload pools from the mmapped files on subsequent runs 5) Pools able to expand as necessary I used a completely free, open source allocator for the malloc/free part of the code (in C), and did the high-level stuff from the Ada. The mmap'ed blocks were mapped as the pool expanded, getting larget maps each time. The pool kept a fixed-size table of all the regions allocated. I don't think I have the code to hand, since it was not mine :( The objectives above probably apply to your code too. I think that region-based allocation is an important and under-appreciated approach to memory management. I can't remember the exact details of the interface, but I don't think you need bindings to mmap, since they are part of Florist (I still use these in my current code). Good luck! -- Adrian