Re: Unexpected OutOfMemoryError...

[Andrew Haley <aph at redhat dot com>]

gabriel.bianco@pixeon.com.br writes:
 > Citando Andrew Haley <aph@redhat.com>:
 > > I can't reproduce this.  I guess it's probably a Windows-specific thing.
 > > 
 > > The gc calls either VirtualAlloc or GlobalAlloc, depending on how it
 > > is configured.  If either of these fails, the full error information
 > > may be retrieved by calling GetLastError.
 > > 
 > > If I were you, I'd go into os_dep.c and add a bunch of trace
 > > information to GC_win32_get_mem to see why the gc is failing to
 > > allocate memory.
 > 
 > Took me a while, but I finally learned how to compile it... But it didn't show
 > anything interesting, no errors.
 > 
 > I've attached the output of the test, but the error doesn't seem to be in
 > GC_win32_get_mem(). It calls VirtualAlloc(), but never fails...
 > 
 > It only calls GC_win32_get_mem() a few times. The OutOfMemoryError exception is
 > thrown from somewhere else.

Ah, now, that is _very_ interesting.  The gc calls GC_oom_fn, which
points to out_of_memory in libjava/boehm.cc:

static void * handle_out_of_memory(size_t)
{
  _Jv_ThrowNoMemory();
}

Note that the size_t parameter is interesting: it tells you how big
the failing memory request was.  It would be good to print that.  If
you have gdb, you can put a breakpoint on handle_out_of_memory.

Also, see doc/README.environment:

GC_PRINT_STATS - Turn on as much logging as is easily feasible without
		 adding signifcant runtime overhead.  Doesn't work if
		 the collector is built with SMALL_CONFIG.  Overridden
		 by setting GC_quiet.  On by default if the collector
		 was built without -DSILENT.

Andrew.