Re: 'image and memory allocation

Re: 'image and memory allocation

[dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!mips!sdd.hp.com!elroy.]

In article <9204201756.AA00601@blackwidow.Jpl.Nasa.Gov> blc@BLACKWIDOW.JPL.NASA
.GOV (Bruce L. Conroy) writes:
>In message <1992Apr15.175641.5785@puffin.uucp> Pete Carah writes
>
>> Well, with Meridian (and probably most other ada systems), if you use 'image
>> for ANY type too long you will run out of memory.  The return value of 'imag
e
>> is a dynamic string, which is NEVER DEALLOCATED.  I'm not sure if
...
>In fact there are two problems here. Although Meridian did have a
>problem in their version 2.0 compiler, it was fixed in the 2.1 release.

Guess again; we started with 2.2.  Still there in 4.1... (at least for
our application).

>The key to deallocation of dynamic strings is to leave the frame of reference.
>Any Ada program which allocates dynamic memory in a tight loop will eventually
>crash. The solution however is simply to leave the frame of reference at 
>least once per loop. This can be done by putting a BEGIN ... END around the
>statement that allocates the memory, or by putting it inside a function 
>call.

I'll try that.  However, this is a trick that someone using only the LRM
for a reference would never come up with.  A reassignment to the same
pointer (oops, access variable) should be able to automatically do the
same thing (though I don't know if even PL/I did that) in order for a
naive programmer writing a simple DP-type program to make it work easily.
I'm thinking here of a typical "fast" program that you would write in
an hour or less (e.g. five minutes) in AWK.

Note that often simple DP progs have a single loop at the top level,
and SHOULD work on extensible data sets.  The trick you give is simply
that, a trick, and shouldn't be necessary (besides, NO manual documents
it.  Another real solution is to use 'image (and other string ops;
concatenation does this too) for debugging only).  Of course, this makes
your program unreadable, as in C where the string ops are all explicit
calls...
However, if the output is to be in neat columns, string ops are
undesireable anyhow as they give unpredictable sizes.

Also, Robert Eachus sent me a "test" program that doesn't use that trick
which he says works in verdix on a sparc and doesn't "grow" memory.

In it, the string returned by integer'image is never assigned, it only has
a character picked out and tested.  For this test, integer'image could
return a pointer to the same string every time (like, say, unix ctime()) and
the program would still work.
I would call this a "proper" implementation, though it only tests part of the
original problem (e.g. try concats of several 'image calls with other
strings).

I haven't yet tried this one in Meridian on a PC; I should be able to on
Friday.

------------------------------------------------------------
with Text_IO;
procedure Image_Test is
  T,Keep: Character := ' ';
begin
  Text_IO.Set_Line_Length(18);
  for I in 1..999_999 loop
    T := Integer'IMAGE(I)(2);
    if T /= Keep then Text_IO.Put(T); Keep := T; end if;
  end loop;
  Text_IO.New_Line;
  Text_IO.Put_Line("All Done!");
end Image_Test;
-------------------------------------------------------------

>    Bruce Conroy

-- Pete

Re: 'image and memory allocation

[Bill Yow]

In article <1992Apr23.164302.15348@puffin.uucp>, pete@puffin.uucp writes:

Stuff Deleted

|> Note that often simple DP progs have a single loop at the top level,
|> and SHOULD work on extensible data sets.  The trick you give is simply
|> that, a trick, and shouldn't be necessary (besides, NO manual documents

The Manual for version Meridian Ada 4.1 documents that problem.

Check page 9 of the Meridian Ada Compiler User's Guide under the section
Using the Compiler.

2.4.4 Catenation (&) and Storage Reclamation

... Has a paragraph about the problem and a sample program.


|> it.  Another real solution is to use 'image (and other string ops;
|> concatenation does this too) for debugging only).  Of course, this makes
|> your program unreadable, as in C where the string ops are all explicit
|> calls...
|> However, if the output is to be in neat columns, string ops are
|> undesireable anyhow as they give unpredictable sizes.
> -------------------------------------------------------------

Stuff Deleted

|> 
|> >    Bruce Conroy
|> 
|> -- Pete

						Later,
						Bill Yow
						(713) 283-4051
						yow@sweetpea.jsc.nasa.gov
						byow@mcimail.com

My opinions are my own!			

Re: 'image and memory allocation

[rlk]

pete@bloom-beacon.mit.edu writes:

> >Any Ada program which allocates dynamic memory in a tight loop will eventual
ly
> >crash. The solution however is simply to leave the frame of reference at 
> >least once per loop. This can be done by putting a BEGIN ... END around the
> >statement that allocates the memory, or by putting it inside a function 
> >call.
> 
> I'll try that.  However, this is a trick that someone using only the LRM
> for a reference would never come up with.  A reassignment to the same
> pointer (oops, access variable) should be able to automatically do the
> same thing (though I don't know if even PL/I did that) in order for a
> naive programmer writing a simple DP-type program to make it work easily.
> I'm thinking here of a typical "fast" program that you would write in
> an hour or less (e.g. five minutes) in AWK.

Naive programmers should not be writing programs in one hour that are 
expected to run forever, no?   This is one of those areas that code
inspections and code reviews add value to the software engineering 
process.  

> Note that often simple DP progs have a single loop at the top level,
> and SHOULD work on extensible data sets.  The trick you give is simply
> that, a trick, and shouldn't be necessary (besides, NO manual documents
> it.  

Of course, if your manual doesn't document where dynamic memory is used,
then it's got a problem.  I don't think that it should be up to the
Ada Reference Manual to document such implementation-dependent issues.

IMHO, of course.

	.Bob.