* Help-memory allocation @ 2003-06-30 9:11 prashna 2003-06-30 9:14 ` Vinzent Hoefler ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: prashna @ 2003-06-30 9:11 UTC (permalink / raw) Hi all, How to check whether the memory is allocated or not when using new operator?in other words, what the operator "new" returns if memory allocation fails?Surprisingly no tutorial or book mentions what it returns or is that this "new"(Ada) is entirely different from C++ "new" or C's malloc. Any pointers on this will be appreciated. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 9:11 Help-memory allocation prashna @ 2003-06-30 9:14 ` Vinzent Hoefler 2003-06-30 10:30 ` Rodrigo Garcia 2003-06-30 14:56 ` Florian Weimer 2003-07-02 15:59 ` Richard Riehle 2003-07-02 22:35 ` Matthew Heaney 2 siblings, 2 replies; 15+ messages in thread From: Vinzent Hoefler @ 2003-06-30 9:14 UTC (permalink / raw) prashna wrote: >How to check whether the memory is allocated or not when using new >operator?in other words, what the operator "new" returns if memory >allocation fails? I'd say, it raises the Storage_Error exception. Vinzent. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 9:14 ` Vinzent Hoefler @ 2003-06-30 10:30 ` Rodrigo Garcia 2003-06-30 14:56 ` Florian Weimer 1 sibling, 0 replies; 15+ messages in thread From: Rodrigo Garcia @ 2003-06-30 10:30 UTC (permalink / raw) Vinzent is right. Look at: ARM 4.8 (14). Rodrigo "Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote in message news:bdov56$v7na6$1@ID-175126.news.dfncis.de... prashna wrote: >How to check whether the memory is allocated or not when using new >operator?in other words, what the operator "new" returns if memory >allocation fails? I'd say, it raises the Storage_Error exception. Vinzent. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 9:14 ` Vinzent Hoefler 2003-06-30 10:30 ` Rodrigo Garcia @ 2003-06-30 14:56 ` Florian Weimer 2003-06-30 15:25 ` Vinzent Hoefler 2003-07-01 9:06 ` prashna 1 sibling, 2 replies; 15+ messages in thread From: Florian Weimer @ 2003-06-30 14:56 UTC (permalink / raw) Vinzent Hoefler <ada.rocks@jlfencey.com> writes: >>How to check whether the memory is allocated or not when using new >>operator?in other words, what the operator "new" returns if memory >>allocation fails? > > I'd say, it raises the Storage_Error exception. In conforming implementations, yes. However, many Ada implementations will only raise Storage_Error at some later point in the execution of the program ("commit on allocate" vs. "commit on use"). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 14:56 ` Florian Weimer @ 2003-06-30 15:25 ` Vinzent Hoefler 2003-06-30 16:56 ` ` (2 more replies) 2003-07-01 9:06 ` prashna 1 sibling, 3 replies; 15+ messages in thread From: Vinzent Hoefler @ 2003-06-30 15:25 UTC (permalink / raw) Florian Weimer wrote: >Vinzent Hoefler <ada.rocks@jlfencey.com> writes: > >>>How to check whether the memory is allocated or not when using new >>>operator?in other words, what the operator "new" returns if memory >>>allocation fails? >> >> I'd say, it raises the Storage_Error exception. > >In conforming implementations, yes. However, many Ada implementations >will only raise Storage_Error at some later point in the execution of >the program ("commit on allocate" vs. "commit on use"). Mmh, so in case someone relies on the occurence of the exception in the very moment of the allocation, would it be wise to also give an initial value to make sure we actually "use" the allocated memory? Vinzent. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 15:25 ` Vinzent Hoefler @ 2003-06-30 16:56 ` 2003-07-01 9:15 ` Florian Weimer 2003-07-01 8:58 ` Florian Weimer 2003-07-03 7:24 ` Robert I. Eachus 2 siblings, 1 reply; 15+ messages in thread From: @ 2003-06-30 16:56 UTC (permalink / raw) Vinzent Hoefler wrote: > Florian Weimer wrote: > > >>Vinzent Hoefler <ada.rocks@jlfencey.com> writes: >> >> >>>>How to check whether the memory is allocated or not when using new >>>>operator?in other words, what the operator "new" returns if memory >>>>allocation fails? >>> >>>I'd say, it raises the Storage_Error exception. >> >>In conforming implementations, yes. However, many Ada implementations >>will only raise Storage_Error at some later point in the execution of >>the program ("commit on allocate" vs. "commit on use"). > > > Mmh, so in case someone relies on the occurence of the exception in > the very moment of the allocation, would it be wise to also give an > initial value to make sure we actually "use" the allocated memory? > > > Vinzent. I do not think this is necessary. Look at the dynamic semantics of allocators: even for uninitialized allocators, an object of the designated subtype is created and any implicit initial value is assigned. That is, allocation actually takes place when "new" is done. Florian, which Ada implementation are you using that is not conforming to the standard? Why do you say "many" Ada implementations are not conforming? Which ones? Rodrigo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 16:56 ` @ 2003-07-01 9:15 ` Florian Weimer 0 siblings, 0 replies; 15+ messages in thread From: Florian Weimer @ 2003-07-01 9:15 UTC (permalink / raw) Rodrigo Garc�a <rodrigo.garcia.ARROBA.epfl.ch> writes: > I do not think this is necessary. Look at the dynamic semantics of > allocators: even for uninitialized allocators, an object of the > designated subtype is created and any implicit initial value is > assigned. That is, allocation actually takes place when "new" is done. Yes, that's why commit-on-use is non-conforming. 8-) However, commit-on-use is the default on many systems (and switching to commit-on-allocate requires non-trivial modifcations on some systems), and it's the most usable configuration on almost any system, unless you run very special software. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 15:25 ` Vinzent Hoefler 2003-06-30 16:56 ` @ 2003-07-01 8:58 ` Florian Weimer 2003-07-03 6:53 ` prashna 2003-07-03 7:24 ` Robert I. Eachus 2 siblings, 1 reply; 15+ messages in thread From: Florian Weimer @ 2003-07-01 8:58 UTC (permalink / raw) Vinzent Hoefler <ada.rocks@jlfencey.com> writes: > Mmh, so in case someone relies on the occurence of the exception in > the very moment of the allocation, would it be wise to also give an > initial value to make sure we actually "use" the allocated memory? In most cases, yes. There are systems which can merge zero pages even after they have been written to. However, some systems behave very wildly in out-of-memory situations, killing random processes etc. Better make sure that you always have enough memory available. 8-/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-07-01 8:58 ` Florian Weimer @ 2003-07-03 6:53 ` prashna 0 siblings, 0 replies; 15+ messages in thread From: prashna @ 2003-07-03 6:53 UTC (permalink / raw) >Better make sure that you always have enough memory available. 8-/ How to check whether enough is memory is avaliable or not before allocating? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 15:25 ` Vinzent Hoefler 2003-06-30 16:56 ` 2003-07-01 8:58 ` Florian Weimer @ 2003-07-03 7:24 ` Robert I. Eachus 2 siblings, 0 replies; 15+ messages in thread From: Robert I. Eachus @ 2003-07-03 7:24 UTC (permalink / raw) Vinzent Hoefler wrote: > Mmh, so in case someone relies on the occurence of the exception in > the very moment of the allocation, would it be wise to also give an > initial value to make sure we actually "use" the allocated memory? Dave Emery likes to describe Storage_Error as a parachute that opens on impact. The problem is not in the definition of allocators, but that there may be temporary storage used when evaluating an expression. So the allocator can use up almost but not quite all of the storage, and you will then get a Storage_Error exception somewhere downstream. Unless you carefully track how much storage is used by your program and where, you have to allow for the possibility of Storage_Error anywhere. Of course, on a decent virtual memory system, most programs will use so little memory compared to the (virtual) Gigabytes allocated to that process that Storage_Error will only occur if you run out of disk space. There are cases in Ada where handling Storage_Error is useful. For example if you are potentially creating a large object on the stack, not the heap. But in other cases all Storage_Error tells you is that you crashed. Actually, there is an even worse case. You can have a handler for Storage_Error in just the right place, and catch Storage_Error when it occurs--but then the exception handler uses some memory and boom! Storage_Error is raised again, outside the error handler. Nice OSes save a block at the end of the stack which is released when a stack allocation error occurs so that the first Storage_Error can be handled nicely. But such a block can only be used reliably once per process. -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 14:56 ` Florian Weimer 2003-06-30 15:25 ` Vinzent Hoefler @ 2003-07-01 9:06 ` prashna 2003-07-01 9:17 ` Florian Weimer 1 sibling, 1 reply; 15+ messages in thread From: prashna @ 2003-07-01 9:06 UTC (permalink / raw) > > In conforming implementations, yes. However, many Ada implementations > will only raise Storage_Error at some later point in the execution of > the program ("commit on allocate" vs. "commit on use"). Don't you think "commit on allocate" is better choice? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-07-01 9:06 ` prashna @ 2003-07-01 9:17 ` Florian Weimer 2003-07-01 12:21 ` 0 siblings, 1 reply; 15+ messages in thread From: Florian Weimer @ 2003-07-01 9:17 UTC (permalink / raw) vashwath@rediffmail.com (prashna) writes: > Don't you think "commit on allocate" is better choice? At least on UNIX systems with a few typical UNIX services, the situations in which the system continues to run in commit-on-use mode is a proper subset of the situations for commit-on-allocate mode. So commit-on-use is the better choice. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-07-01 9:17 ` Florian Weimer @ 2003-07-01 12:21 ` 0 siblings, 0 replies; 15+ messages in thread From: @ 2003-07-01 12:21 UTC (permalink / raw) Florian Weimer wrote: > vashwath@rediffmail.com (prashna) writes: > > >>Don't you think "commit on allocate" is better choice? > > > At least on UNIX systems with a few typical UNIX services, the > situations in which the system continues to run in commit-on-use mode > is a proper subset of the situations for commit-on-allocate mode. So > commit-on-use is the better choice. Ok Florian, you convinced me. I know that GNAT uses malloc for memory allocation on its Linux implementation. Looking at malloc man page, one can read in the last paragraph: "Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer." So I guess this is normal in the case of systems with virtual memory. Rodrigo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 9:11 Help-memory allocation prashna 2003-06-30 9:14 ` Vinzent Hoefler @ 2003-07-02 15:59 ` Richard Riehle 2003-07-02 22:35 ` Matthew Heaney 2 siblings, 0 replies; 15+ messages in thread From: Richard Riehle @ 2003-07-02 15:59 UTC (permalink / raw) prashna wrote: > Hi all, > How to check whether the memory is allocated or not when using new > operator?in other words, what the operator "new" returns if memory > allocation fails?Surprisingly no tutorial or book mentions what it > returns or is that this "new"(Ada) is entirely different from C++ > "new" or C's malloc. > Any pointers on this will be appreciated. Where this could be a problem, use the Storage_Pools package. GNAT has a default version of this. I think other compiler publishers should have a default version, but not all do. There is a great example of how to use this package in John Barnes' book. Also, several people (Pat Rogers or Jim Rogers?) have posted good examples in this forum. Richard Riehle ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Help-memory allocation 2003-06-30 9:11 Help-memory allocation prashna 2003-06-30 9:14 ` Vinzent Hoefler 2003-07-02 15:59 ` Richard Riehle @ 2003-07-02 22:35 ` Matthew Heaney 2 siblings, 0 replies; 15+ messages in thread From: Matthew Heaney @ 2003-07-02 22:35 UTC (permalink / raw) vashwath@rediffmail.com (prashna) wrote in message news:<d40d7104.0306300111.204fc99e@posting.google.com>... > How to check whether the memory is allocated or not when using new > operator?in other words, what the operator "new" returns if memory > allocation fails? The exception Storage_Error is raised if the allocation fails. > Surprisingly no tutorial or book mentions what it > returns or is that this "new"(Ada) is entirely different from C++ > "new" or C's malloc. No book mentions that Ada's allocator new is different from the C++ allocator new because they aren't different! They behave identically, in the sense that both raise an exception. (The C++ exception is named std::bad_alloc.) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-07-03 7:24 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-30 9:11 Help-memory allocation prashna 2003-06-30 9:14 ` Vinzent Hoefler 2003-06-30 10:30 ` Rodrigo Garcia 2003-06-30 14:56 ` Florian Weimer 2003-06-30 15:25 ` Vinzent Hoefler 2003-06-30 16:56 ` 2003-07-01 9:15 ` Florian Weimer 2003-07-01 8:58 ` Florian Weimer 2003-07-03 6:53 ` prashna 2003-07-03 7:24 ` Robert I. Eachus 2003-07-01 9:06 ` prashna 2003-07-01 9:17 ` Florian Weimer 2003-07-01 12:21 ` 2003-07-02 15:59 ` Richard Riehle 2003-07-02 22:35 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox