RE: GC Warning: Header allocation failed: Dropping block.

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

For desktop/server apps, that would probably be OK.
For embedded apps, it would have to be adjusted back down.

I think the most significant effect is on LOG_PHT_ENTRIES, which
adjusts the size of what's basically a "set of pages" data structure
that's used in a few places.  With LARGE_CONFIG, those grow from 8K
to 128K.  Altogether, it might add something a bit less than a MB
to the total data size.  The additional memory is not scanned by
the GC, and mostly not touched by small apps.  Thus this is probably
not a big deal.

The alternative is just to increase the default values of some of the
individual constants again.  If we bumped the default value of
LOG_PHT_ENTRIES by 2, we'd be fine up to 1GB heaps (and probably OK
up to 3GB or so), at minimal cost.  I could also do that in the
upstream source.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:mckinlay@redhat.com] 
> Sent: Wednesday, February 16, 2005 3:39 PM
> To: Boehm, Hans
> Cc: Yura Smolsky; java@gcc.gnu.org
> Subject: Re: GC Warning: Header allocation failed: Dropping block.
> 
> 
> Boehm, Hans wrote:
> 
> >It means that the garbage collector's attempt to obtain more memory 
> >from the OS (on Linux it uses sbrk() or mmap()) failed.
> >
> >By default the GC uses as much memory as it thinks it needs 
> and the OS 
> >will give it.  Try running with the GC_PRINT_STATS 
> environment variable 
> >defined, and see what that says.  Also keep something like "top" 
> >running to see whether you are really running out of 
> memory/swap space.  
> >(I'm assuming a Linux environment.)
> >
> >In general, for a large Java heap, you are better off 
> running a recent 
> >gcj.  And ideally the collector should be built with -DLARGE_CONFIG, 
> >which I don't think it is by default.
> >  
> >
> 
> Hans,
> 
> Do you think we should make this the default? Do small apps 
> take much of 
> a hit from -DLARGE_CONFIG?
> 
> Bryce
> 
>