Unexpected OutOfMemoryError...

gabriel.bianco@pixeon.com.br gabriel.bianco@pixeon.com.br
Tue Dec 5 20:11:00 GMT 2006


I think I kind of solved it... :P
After searching a little bit deeper, I managed to understand why
GC_alloc_large() will, after a failed call to GC_allochblk(), sometimes call it
again and other times it will throw the exception.
It seems that, after a failed GC_allochblk(), it calls GC_collect_or_expand()
which will return 'true' if it managed to free or allocate some new memory. 
After a few large allocations, there is no more room to expand so all it can
do is collect. When GC_should_collect() returns 'false', it doesn't attempt to
collect (as it should, from my perspective :P). 
Finally, if it isn't supposed to collect and it didn't manage to expand,
if(GC_fail_count++ < GC_max_retries) it will try to call GC_gcollect_inner()
and return true (notifying GC_alloc_large() to try again).
So, at this point, the problem is that GC_max_retries is set to 0 and the only
place I can see it being set to anything else is in misc.c:
char * sz_str = GETENV("GC_MAXIMUM_HEAP_SIZE");
if (sz_str != NULL) {
 word max_heap_sz = (word)atol(sz_str);
 if (max_heap_sz < initial_heap_sz * HBLKSIZE) {
 WARN("Bad maximum heap size %s - ignoring it.\n",
 sz_str);
 } 
 if (0 == GC_max_retries) GC_max_retries = 2;
 GC_set_max_heap_size(max_heap_sz);
}
Unless I set the enviroment variable GC_MAXIMUM_HEAP_SIZE, GC_max_retries will
always be 0.
I changed it to 2 in code, and it works, never throws a single
OutOfMemoryError,
no need for those OutOfMemory recoveries...
But still, I guess the real error might be GC_should_collect(). Given that the
program needs memory and couldn't expand, it seems that a collection necessary,
why not go for it? I mean, not as a retry, but just the end of a try...


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /