[Gc] Out of Memory! Returning NIL!

Boehm, Hans hans.boehm at hp.com
Tue Nov 14 11:55:37 PST 2006

That happens after the heap is already quite large, and it is controlled
by MAXHINCR defined in gc_priv.h.  It's also expected behavior, since
the collector would rather allocate the heap in fewer, larger segments.
Normally the only cost is that you may end up with up to 16MB of
allocated address space per (large) process that isn't really being
The question is really why GC_expend_hp_inner() is called so many times.


	From: Simon Tsai [mailto:mtsai at adobe.com] 
	Sent: Tuesday, November 14, 2006 11:00 AM
	To: Boehm, Hans
	Cc: gc at napali.hpl.hp.com; gc at napali.hpl.hp.com
	Subject: RE: [Gc] Out of Memory! Returning NIL!

	After debug, I found the following information's:


	GC_collect_or_expand(needed_blocks, ignore_off_page)


	    blocks_to_get = 4096;






	bytes = n * HBLKSIZE; 

	    bytes = 4096 * 4096 = 16777216;





	Why blocks_to_get grow so big? Is any way to reduce this number?
>From Task manager, I saw VM size grow to 1.9 GByte. 







	From: Boehm, Hans [mailto:hans.boehm at hp.com] 
	Sent: Monday, November 13, 2006 5:53 PM
	To: Simon Tsai
	Cc: gc at napali.hpl.hp.com
	Subject: RE: [Gc] Out of Memory! Returning NIL!


	It would be useful to look at a more complete GC log (either
define the GC_PRINT_STATS environment variable, or compiler the
collector without -DSILENT).


	Assuming your application normally uses much less than 1 GB,
possible causes are:


	1) You are allocating large objects containing seemingly random
bit-patterns.  If that's the case, these may appear to the collector to
be pointers.  The C++ proposal addresses this issue with declaration
that allow the implementation to use type information.  For now, the
standard solution is to make sure GC_malloc_atomic is used for those
objects.  You should see this as very little memory reclaimed by the GC
and regular heap expansions, with a large final heap size.


	2) You are internally using some form of custom allocation by
obtaining pools of objects from the collector.  This is generally not a
good idea with a garbage collector.  Symptoms will probably be similar.


	3) This is caused by a single huge allocation request due to
memory corruption.  This should be apparent form the log.


	4) Something else.





		From: gc-bounces at napali.hpl.hp.com
[mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Simon Tsai
		Sent: Monday, November 13, 2006 4:12 PM
		To: gc at napali.hpl.hp.com
		Subject: [Gc] Out of Memory! Returning NIL!



		I have integrated gc 6.8 library with my applications
under Windows XP. My system has 1GByte memory. Our application has used
smart heap. The application is muti-thread.  I saw gc.log has following


		"Out of Memory!  Returning NIL!" and 

		"GC Warning: Thread stack pointer 0x5c9f018 out of
range, pushing everything".



		Does anyone know what cause this problem and how to fix







-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20061114/617725af/attachment.htm

More information about the Gc mailing list