GC Warning: Header allocation failed: Dropping block.

[Boehm, Hans]

So much for my theory ...

It looks like the sbrk segment is the one starting at 09286000,
and growing nicely.  It doesn't run into anything.

My next steps would be:

1) Run strace -ff on the project, or set a breakpoint in sbrk(), to make
sure that sbrk is actually failing.

2) If it isn't, then this sounds like a GC bug.  (Presumably
GC_MAXIMUM_HEAP_SIZE is not set?)

3) If it is failing, as I expect, then this may be a kernel
configuration issue,
unrelated to gcj.

The previous discussion on this list about Linux over-commit
accounting may also be relevant, though the original poster there
had the opposite problem.  See
http://gcc.gnu.org/ml/java/2005-02/msg00094.html.

Is the problem reproducible on more than one machine?  Is the kernel
configuration standard?

Hans

> -----Original Message-----
> From: Yura Smolsky [mailto:info@altervision.biz] 
> Sent: Friday, February 18, 2005 12:34 PM
> To: Boehm, Hans
> Cc: java@gcc.gnu.org
> Subject: Re[4]: GC Warning: Header allocation failed: Dropping block.
> 
> 
> Hello, Hans.
> 
> >> Here is log produced with 'export GC_PRINT_STATS=1'
> >> See attached 'gc.log'.
> BH> I assume this is x86/Linux?
> yes
> 
> I have tried to get gcc snapshot (Feb 13th) and compile gcj 
> with -DLARGE_CONFIG and -DUSE_MMAP. Well, this have not 
> changed situation... It's weird.
> 
> I have attached gc.log which is log for GC_PRINT_STATS and 
> out.log which is output of program (with GC_PRINT_ADDRESS_MAP=1)
> 
> BH> Gcj normally uses a collector that's configured to grow the heap 
> BH> with sbrk.  (We thought that had been changed.  But it 
> wasn't really 
> BH> changed until two days ago.)
> 
> Well, I have tried cvs gcc, but it has some errors, so I got snapshot.
> 
> BH> It may be that the heap is running into a thread stack, and hence 
> BH> can't grow very much.
> 
> BH> Running the program with GC_PRINT_ADDRESS_MAP might confirm or 
> BH> refute this.
> 
> Please, see out.log
> 
> BH> If my guess is correct, building the collector with -DUSE_MMAP 
> BH> should help.  (Checking out and building todays CVS 
> sources should 
> BH> do that, but may not be what you want.)
> 
> We have used this option too. I hope my logs will give you 
> ideas.. Maybe I need to provide you with more information?
> 
> Yura Smolsky.
>