This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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.
Attachment:
gc.log
Description: Binary data
Attachment:
out.log
Description: Binary data
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |