[Gc] Out of Memory! Returning NIL!

Simon Tsai mtsai at adobe.com
Wed Nov 15 14:11:54 PST 2006


I set break point at "Thread stack pointer out of range". I found
because program called GC_gcollect from another thread. Because this
program is a muti-thread process. I need figure out how to modify this.
Does this cause problems? 

>> The collection numbers are not monotonically increasing, the heap
size
suddenly jumps without indication of heap expansion.

It's a muti-thread program. Where is the place I can check for this?

Thanks,

simon

-----Original Message-----
From: Boehm, Hans [mailto:hans.boehm at hp.com] 
Sent: Tuesday, November 14, 2006 5:59 PM
To: Simon Tsai
Cc: gc at napali.hpl.hp.com
Subject: RE: [Gc] Out of Memory! Returning NIL!

The log (not posted due to size) starts to look very problematic around
here:

--> Marking for collection 6 after 0 allocd bytes + 0 wasted bytes
Collection 5 reclaimed 0 bytes ---> heapsize = 1458176 bytes
World-stopped marking took 16 msecs
Bytes recovered before sweep - f.l. count = 0
Immediately reclaimed 0 bytes in heap of size 1458176 bytes(0 unmapped)
0 (atomic) + 112396 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 16 msecs
Initiating full world-stop collection 7 after 0 allocd bytes
0 bytes in heap blacklisted for interior pointers
--> Marking for collection 7 after 0 allocd bytes + 0 wasted bytes
Collection 6 reclaimed 0 bytes ---> heapsize = 1458176 bytes
World-stopped marking took 15 msecs
Bytes recovered before sweep - f.l. count = 0
Immediately reclaimed 0 bytes in heap of size 1458176 bytes(0 unmapped)
0 (atomic) + 112396 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 31 msecs
Initiating full world-stop collection 8 after 0 allocd bytes
0 bytes in heap blacklisted for interior pointers

The collection numbers are not monotonically increasing, the heap size
suddenly jumps without indication of heap expansion, log entries are
interleaved, eventhough I think they should all be protected by the
allocation lock, and warning messages about the thread stack pointer
start appearing.  I have no idea what's going on, but it's very strange.
Did you somehow get two copies of the GC linked in?  Was there some
other opportunity for the log to get garbled?

It may be easiest to debug this by either setting a break point where
the "Thread stack pointer out of range" is generated, and seeing why the
collector sees a bad stack pointer, or by trying to understand why
GC_gc_no seems to go backwards.

Hans






More information about the Gc mailing list