Help-memory allocation

Help-memory allocation

[prashna]

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.

Re: Help-memory allocation

[Vinzent Hoefler]

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.

Re: Help-memory allocation

[Rodrigo Garcia]

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.

Re: Help-memory allocation

[Florian Weimer]

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").

Re: Help-memory allocation

[Vinzent Hoefler]

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.

Re: Help-memory allocation

[@ 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

Re: Help-memory allocation

[Florian Weimer]

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.

Re: Help-memory allocation

[Florian Weimer]

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

Re: Help-memory allocation

[prashna]

>Better make sure that you always have enough memory available. 8-/
How to check whether enough is memory is avaliable or not before allocating?

Re: Help-memory allocation

[Robert I. Eachus]

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.

Re: Help-memory allocation

[prashna]

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

Re: Help-memory allocation

[Florian Weimer]

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.

Re: Help-memory allocation

[@ 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

Re: Help-memory allocation

[Richard Riehle]

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

Re: Help-memory allocation

[Matthew Heaney]

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.)