GC Warning: Header allocation failed: Dropping block.

Mon Feb 21 07:01:00 GMT 2005

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
BH> heap with sbrk. (We thought that had been changed. But it wasn't
BH> really 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
BH> or 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.log
Type: application/octet-stream
Size: 232959 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050221/ea40f762/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.log
Type: application/octet-stream
Size: 27995 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050221/ea40f762/attachment-0001.obj>