you wrote 84 lines
On Fri, Mar 21, 2003 at 02:04:39PM +0100, Michael Van Canneyt wrote:
> On Fri, 21 Mar 2003, Anton Tichawa wrote:
> > On Friday 21 March 2003 13:09, you wrote:
> > > > On Friday 21 March 2003 12:29, you wrote:
> > > >> >> > But, when I use fail in my simple example program, it returns
> > > >> >>
> > > >> >> NIL okay but
> > > >> >>
> > > >> >> > the Heaptrace function tells me I have two unfreed memory
> > > >> >> > blocks
> > > >>
> > > >> (36
> > > >>
> > > >> >> > bytes).
> > > >> >> > I can't see a memory leak anywhere else in that program, what
> > > >> >>
> > > >> >> could cause
> > > >> >>
> > > >> >> > this? (Heaptrace output is as follows: I am using FPC 1.0.6
> > > >> >> > btw)
> > > >> >>
> > > >> >> [snip heap dump]
> > > >> >>
> > > >> >> That is the exception frame that is left on the heap. I don't
> > > >> >> have
> > > >>
> > > >> the
> > > >>
> > > >> >> time to analyze what the cause is that the exception frame is
> > > >> >> not removed.
> > > >> >
> > > >> > It may be a bug in 1.0.6 which has subsequently been fixed. I
> > > >>
> > > >> downloaded
> > > >>
> > > >> > and
> > > >> > installed the 1.1 snapshots and compiled the same source code,
> > > >> > and the memory leak vanishes....
> > > >>
> > > >> The reason why 1.1 has no leak is that it uses the stack to store
> > > >> the exception frames. The real problem is still there, because
> > > >> exception stack
> > > >> is still not updated
> > > >
> > > > some months ago i had a discussion with a friend, converning global
> > > > (static,
> > > > absolute) variables. his point of view was that they're not
> > > > necessary when using oop; mine was, sometimes they're absoulutely
> > > > necessary.
> > > >
> > > > if we have just one level of exception processing above normal
> > > > program execution (i. e. while an exception is being processed, no
> > > > other exception will gain control), we can use absolute variables
> > > > for the exception frame.
> > > >
> > > > it's even possible to define a fixed whole number of exception
> > > > layers and allocate absolute memory for N exception levels.
> > > >
> > > > that memory space would not get lost, as it can be saved by
> > > > allocating the 'normal' stack or 'normal' heap more tightly - the
> > > > old system has to reserve
> > > > exception spae implicitely on the stack or on the heap.
> > > >
> > > > what do you think about that?
> > >
> > > It does not fix the problem, the frame is then still left on the
> > > stack.
> > >
> > > The allocation on the heap has already been changed to allocation on
> > > the stack in 1.1, because hat is much faster. Using a predefined
> > > storage of N exception levels is adding a limit and that is something
> > > we want to prevent.
> >
> > but also the power-switch, the data bus width, and the exception
> > vectors in ROM now are limits. i think limits cannot be prevented, but
> > they can be chosen knowingly, harmonic, and safe or so. every limit
> > should include the overhead to overcome it later, as things get better.
>
> Not in this case. For instance recursive routines will get in trouble.
> There is no way to know how deep the stack can be nested, so you cannot
> foresee this. Putting a limit on that is out of the question.
Agreed. If you put a limit on that, you will disallow algorithms that
use resursive loops. There are many that do ...
provided that noone has posted that before, and that safe email processing allows me to post another argument, i'd say that:
if memory is limited, unlimitedly recursive procedures are responsible to check stack space, aren't they?
but if it's possible to define a maximum N, the check need be made only once, and the procedure will run faster. there's a kind of tradeoff between freedom and efficiency, isn't there?
also, if i remember right, anything that can be done recursively can also be done by applying a non-recursive algorithm. if that's true, recursive formulae are just comfortable, aren't they? that'd be a tradeoff between speed of programming and efficiency, wouldn't it?
anton.
----------
"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."
Doris Langley Moore: Ada, Countess of Lovelace (London 1977).
----------
Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:
----------