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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6c13cc000274246b
X-Google-Attributes: gid103376,public
From: Stephen Leake <Stephen.Leake@gsfc.nasa.gov>
Subject: Re: Please Help.
Date: 1997/09/19
Message-ID: <3422BE2E.62B1@gsfc.nasa.gov>#1/1
X-Deja-AN: 273881572
References: <01bcbcde$f8a425c0$ca70fe8c@default> <dewar.873989183@merv>
 <5vaude$q20$1@goanna.cs.rmit.edu.au> <5vbiid$luu$1@goanna.cs.rmit.edu.au>
 <34197042.7CFC@gsfc.nasa.gov> <dewar.874165401@merv>
 <341D4041.4AF8@gsfc.nasa.gov> <dewar.874434176@merv>
 <342005BE.5C4E@gsfc.nasa.gov> <dewar.874604078@merv>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Reply-To: Stephen.Leake@gsfc.nasa.gov
Newsgroups: comp.lang.ada
Date: 1997-09-19T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert Dewar wrote:
> 
> <<The downside is heap fragmentation, which will bite you just when it
>   costs the most to fix. Controlled types can guarantee no dangling
>   pointers; they do not guarantee no heap fragmentation. For that you need
>   compacting storage pools (or very careful use of Unbounded_Strings).
> 
>   Is there a requirement in Ada 95 to document whether the
>   Unbounded_Strings implementation is compacting? This would be useful
>   information; I haven't seen it in Annex M for ObjectAda, but I don't
>   believe I've read the whole thing.>>
> 
> Well these days on typical machines, fragmentation just translates into
> poorer performance because of more paging. But compacting may or may not
> help to reduce paging. It is not a clear call at all

Ok, for typical users on hosts with virtual memory. I have seen systems
that run under Windows 95 where paging due to non-compacting reduced
performance to the point where it was unacceptable. If I do get to a
situation like this, I would like to be able to determine whether the
run-time library is compacting or not.

In the context of an embedded system with (no virtual memory) that has
to run forever? Then compacting (or not using dynamic strings) becomes a
requirement.
 
> There is no requirement for documenting this, since there is no imagination
> of compacting being an issue. (there is also no requirement to document
> whether your storage allocator reads the CMOS clock, or takes locks, or
> makes direct BIOS calls, or allocates more than it needs to, or anything
> else!)

I can measure the time it takes to execute my code (that seems to be the
primary effect of the other things you list). Measuring how much memory
is allocated can be done (to  first approximation) by simpler pointer
subtraction.  But I cannot measure heap fragmentation, at least not
without support from the compiler/run-time vendor (a heap display tool).
Thus it should be in the documentation, at least for the Real-Time
Systems Annex.

If I have a reasonable relationship with the compiler vendor, I should
be able to get any information I need, without it being part of the Ada
standard. But I feel strongly that this issue (compacting dynamic
memory) is ignored by too many programmers, so I'd like to raise its
visibility.

-- 
- Stephe