Re[6]: GC Warning: Header allocation failed: Dropping block.

[Yura Smolsky <info at altervision dot biz>]

Hello, Hans.

Well, I have solved this puzzle :)
Last time I was not compiling gcj correctly.
-DLARGE_CONFIG and -DUSE_MMAP works!

You should make them "on" by default.

Great Thanks for Your Help!

BH> So much for my theory ...

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

BH> My next steps would be:

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

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

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

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

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

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




Yura Smolsky.