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,cb73ffe253a5caf1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Memory management clarification Date: 26 Jul 2005 13:45:10 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1122399910 24977 192.74.137.71 (26 Jul 2005 17:45:10 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 26 Jul 2005 17:45:10 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3792 Date: 2005-07-26T13:45:10-04:00 List-Id: Maciej Sobczak writes: > Robert A Duff wrote: > > If you put "for T'Storage_Size use 1_000_000;", then implementations > > should reclaim all memory allocated for type T when the scope of T is > > left. > > Nice. Why putting this arbitrary limit? You can put any limit you like. It does not need to be known at compile time. Note that this feature is inherited from Ada 83. It is subsumed by storage pools (added in Ada 95). > And what does it mean, anyway - is the pool actually pre-allocated with > this size when the for..use... statement is executed, or does it start > empty and later "inflates" as necessary, but no bigger than the given > limit? > The difference is not only the observable memory consumption (even when > not the whole pool is used), but also the possibility and timing of > low-memory errors. It means approximately 1_000_000 storage units are *reserved* for this type. You are guaranteed to be able to allocate (approx) that much. One possible implementation is to allocate that space on the stack of the current procedure, and allocate the heap objects within that. Then it gets automatically freed when the procedure returns. But the implementation is not required to consume the memory -- for example, it can allocate *virtual* address space, but not physical memory or swap space. The timing of out-of-memory errors (Storage_Error exception) is a problem anyway -- according to the standard, you can get Storage_Error at any time. If you don't like the "reserve arbitrary limit" semantics, you can write your own storage pool type that has whatever semantics you like. For example, reserve nothing, but still deallocate on procedure return. The Finalize of the storage pool type comes in handy for that. > > This is not > > a very useful capability, because most access types need to be at > > library level, so the memory won't be reclaimed until the whole program > > is done. > > Indeed, not really useful. > > > You should look up user defined storage pools. You can say: > > for T'Storage_Pool use My_Pool; > > and then you can control when memory will be reclaimed. > > You can reclaim all memory in My_Pool whenever you like -- but > > beware dangling pointers. > > I have to beware them when using Unchecked_Deallocation as well. :) Indeed. ;-) > >>2. > >> > >>loop > >> declare > >> X : MyTypeRef; > >> begin > >> X := new MyType; > >> end; > >>end loop; > >> > >>What now? Is this any different from the memory management point of view? > > No. X.all will never be reclaimed (on most implementations). The only > > difference here is that you're allocating only one object. > > Not really - there's a loop. > I understand that the code above leaks memory, just like my first example. Yes, both leak memory. The loop probably leaks faster. ;-) > > Suppose we added a call P(X) inside the begin/end. And suppose P saves > > X in a global variable. The implementation cannot deallocate the memory > > X points to, because that would leave a dangling pointer in the global > > variable. > > Right, but I was interested exactly in the case where there is just one > reference and it is trivial for the compiler to prove that the object is > not aliased. I don't know of any compiler that does this trivial proof. It's such a special case that it wouldn't be all that useful anyway. >... But without GC there's no difference anyway. > > > >>4. > >> > >>Is it possible to associate some function with object allocated by new, > >>which would be called at the time (or maybe after) the object is > >>reclaimed? > >>Yes, I'm asking about destructors or finalizers. > > Yes. Look up "controlled types". These allow you to associate a > > Finalize operation with a type. For local variables, Finalize will be > > automatically called when the procedure is left. > > Good - this, basically, should allow me to implement some form of local > resource manager (in C++ this idiom is called RAII) that will deallocate > the object (or any other resource) when the scope is left. Right -- it's pretty much the same as in C++. > > For heap objects, > > Finalize will be called when you do Unchecked_Deallocation (or, if you > > never do U_D, when the program is done). > > Fine. Is the order of calling finalizers well-defined for the latter case? I don't remember the exact rules. The order is somewhat left up to the implementation, but you'd have to read the RM to understand the details. > Thank you for these explanations, You're welcome. - Bob