RE: [Fwd: Uninitialized stack gaps and conservative garbage collection]

["Boehm, Hans" <hans dot boehm at hp dot com>]

The collector also tries to address this with a complicated hack that
occasionally checks for opportune times to clear sections of the
stack that are not currently in use.  (See GC_clear_stack()
in misc.c.)

I think this is currently much more sophisticated in the single-threaded
case.  It may be possible to enhance this code to deal with the
problems that were observed.  But it has some inherent limitations.
It only rarely gets control, and it can't clear areas in frames that
are always live when it gets control.  It should handle deep recursions
somewhat acceptably.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Bryce McKinlay
> Sent: Wednesday, May 25, 2005 6:55 AM
> To: Ranjit Mathew
> Cc: java@gcc.gnu.org
> Subject: Re: [Fwd: Uninitialized stack gaps and conservative 
> garbage collection]
> 
> 
> Ranjit Mathew wrote:
> 
> >Interesting stuff found on the GCC list. Doesn't this
> >affect GCJ as well where we use the conservative
> >Boehm GC?
> >  
> >
> >-------- Original Message --------
> >Subject: Uninitialized stack gaps and conservative garbage collection
> >Date: Tue, 24 May 2005 17:40:46 -0400
> >From: Camm Maguire <camm@enhanced.com>
> >Newsgroups: gmane.comp.gcc.devel,gmane.lisp.gcl.devel
> >
> >Greetings!  GCL is a lisp system that compiles to native object code 
> >via the intermediary of gcc.  It uses a conservative garbage 
> collection 
> >algorithm, which means that it walks the C stack to find 
> likely objects 
> >in use by automatic variables, and holds on to these. This 
> works quite 
> >well in practice.
> >
> >For very large systems, the likelihood of holding onto objects which 
> >should be collected increases.  In looking into this, it has 
> come to my 
> >attention that regardless of how carefully the C programmer 
> initializes 
> >variables on the stack, gcc will quite commonly allocate extra space 
> >inaccessbile via any C variable.  These 'stack gaps' can wind up 
> >permanently preventing a large portion of user memory from 
> ever being 
> >collected with this algorithm.
> >
> 
> 
> Sure, with a conservative GC there is always the possibility of 
> uninitialized "junk" on the stack being mis-identified as a valid 
> pointer. There's even the possibility of live non-pointer 
> data, such as 
> an int, being mis-identified as a pointer. Hopefully this is rare in 
> GCJ, however, as the GC only considers pointers to the start of an 
> object to be valid - interior pointers are disregarded, significantly 
> reducing the chance of a mis-identification. On a 64-bit 
> system, due to 
> the larger address space, the chance of this happening 
> reduces even further.
> 
> Bryce
> 
>