GC Warning: Header allocation failed: Dropping block.

Thu Feb 17 19:24:00 GMT 2005

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
>>