[Gc] Out of Memory! Returning NIL!

Simon Tsai mtsai at adobe.com
Tue Nov 14 13:52:41 PST 2006


I checked the gc library (version 6.8) testing program test.c. 

I have written a test program under Windows, it calls GC_INIT(), then it
allocates 800 Mbyte - 1 GByte memory - each time I allocate 10k memory.
I saw the VM Size is 1.2 GByte memory, even after I release (not free)
all memory pointer and called the following functions:

 

                  while (GC_collect_a_little()) { }

                    GC_gcollect();

                    GC_invoke_finalizers();

                  

 

Do I miss anything else? 

 

Thanks,

 

simon

 

________________________________

From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com]
On Behalf Of Boehm, Hans
Sent: Tuesday, November 14, 2006 11:56 AM
To: Simon Tsai
Cc: gc at napali.hpl.hp.com
Subject: RE: [Gc] Out of Memory! Returning NIL!

 

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

 

The question is really why GC_expend_hp_inner() is called so many times.

 

Hans

	 

	
________________________________


	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;

	}

	 

	GC_expand_hp_inner(n)

	{

	n=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. 

	 

	Thanks,

	 

	Simon

	 

	
________________________________


	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.

	 

	Hans

		 

		
________________________________


		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!

		Hi,

		 

		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
erros:

		 

		"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
it?

		 

		Thanks,

		 

		 

		simon

		 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20061114/4a410634/attachment.htm


More information about the Gc mailing list