* 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 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-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-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-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
* 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
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