This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 1.3.4 status?


----- Original Message -----
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: <cygwin-developers@cygwin.com>
Sent: Tuesday, October 23, 2001 11:57 AM
Subject: Re: 1.3.4 status?


>
> ----- Original Message -----
> From: "Christopher Faylor" <cgf@redhat.com>
> To: <cygwin-developers@cygwin.com>
> Sent: Tuesday, October 23, 2001 11:51 AM
> Subject: Re: 1.3.4 status?
>
>
> > On Tue, Oct 23, 2001 at 11:49:11AM +1000, Robert Collins wrote:
> > >----- Original Message -----
> > >From: "Christopher Faylor" <cgf@redhat.com>
> > >To: <cygwin-developers@cygwin.com>
> > >Sent: Tuesday, October 23, 2001 11:27 AM
> > >Subject: Re: 1.3.4 status?
> > >
> > >
> > >> On Tue, Oct 23, 2001 at 11:10:23AM +1000, Robert Collins wrote:
> > >> >Can you mail me the disas for the fhandler_read (with the source
> line
> > >> >tags) ? I don't have time today to build a new dll, but I can
have
> a
> > >> >quick squint...
> > >>
> > >> It's below.
> > >>
> > >
> > >Maybe, I'm blind, but I cannot see the alloca call you mentioned
> > >before..
> >
> > "chkstk" == "alloca"
> >
> > Sorry, I should have mentioned that.  I just figured this out last
> week.
> >
> > It's possible that this is actually a stack boundary check, I guess.
> >
>
> Well it's in the function prolog, so I'd expect it to be that :}.

Ok, here's what alloca does:

on every call, it checks the stack depth. _everything_ allocated from a
call point deeper in the stack is reclaimed, and freed (alloca only uses
the stack to identify when to do stuff, not for storage).

If the size parameter is 0, alloca then returns, otherwise it mallocs a
memory item list header and storage, fills the header in, and returns
the user storage address.

So calling alloca in the prolog of each function is a mechanism to
prevent alloca _not_ freeing memory from a previous function for
extended time period - which will lead to heap fragmentation.

ie.
foo()
{
  bar ();
  bar ();
}
bar ()
{
  goo ();
}
goo ()
{
   ptr x = alloca (4);
}

would never free the two alloc'd blocks during foo() because alloca was
always called at the correct depth.

So gcc transforms that into:
foo ()
{
  alloca (0);
  bar ();
  bar ();
}
bar ()
{
  alloca (0);
  goo ();
}
goo ()
{
  alloca (0);
  ptr x = alloca (4);
}

which will on the second call to bar() free the allocated memory from
the 1st goo invocation.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]