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,4fe0da28a190b761 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!panix!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Storage management Date: Sat, 01 Nov 2008 18:28:04 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <87fxmbog1u.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1225578485 5654 192.74.137.71 (1 Nov 2008 22:28:05 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 1 Nov 2008 22:28:05 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:rajsw+B265ElP2DlMIPDuO8tTrU= Xref: g2news1.google.com comp.lang.ada:2552 Date: 2008-11-01T18:28:04-04:00 List-Id: Florian Weimer writes: > What is the current state of the art with regard to programmer support > for storage management? > > With GNAT, Ada.Finalization adds tons of run-time calls to deal with > abort deferral (even with pragma Restrictions (No_Abort_Statements)), > puts the object on some sort of list, and does some secondary stack > allocations which I don't understand. Clearly, this is not supposed > to be used in performance-critical code, so I doubt it can be used for > a generic smart pointer implementation. (Object allocation in inner > loops is generally a bad idea, but this overhead is also incurred when > copying smart pointers around.) AdaCore is actively working on making finalization much more efficient (e.g. avoiding all those finalization lists, when possible). > Is there some other approach? Can limited types be used to enforce > linearity (in the sense of linear types, cf. > and > )? Yes, you can do better with limited types (derive from Limited_Controlled instead of Controlled). > If it's about pure storage management, GC support would be an option, > too, but AFAIK, you need one of the managed code implementations for > that, or somewhat unsafe libraries (in the sense that you need to > specify which objects are leaf objects, and only store access values > in locations where they are visible to the collector). There is some intention to support proper GC at AdaCore, but it's going to be rather far in the future -- not a whole lot of (paying) customer demand for that. Meanwhile, you can try the Boehm "conservative" GC. My experience is that it works pretty well, so long as you don't use up most of your address space with allocated objects. So on a 64-bit machine, that should work pretty well. Or on a 32-bit machine, if you don't use too much real memory. The ARG is also working on some interesting "region based" schemes. - Bob