Full GC does not run automatically

[GoogleCodeExporter]

Symptom: out-of-memory commit error; the tenured object space just grows
and grows until it crashes, without ever GCing.

Original issue reported on code.google.com by David.Gr...@gmail.com on 22 Sep 2006 at 9:03

[GoogleCodeExporter]

It looks like it crashes deterministically on two machines (athlon XP, P4) under
windows XP at 48 MB of memory space.

run: ByteArray new:1024*1024*45
then GC.
log:
>>[Garbage collection 123 47.5M -> 2.5M, 0.057 secs]

easy way to trigger a crash: 
run: ByteArray new:1024*1024*46
log:
>>commit_memory error 487 0x1e7

>>[A Runtime Error Occurred]
>>Fatal: os::commit_memory failed
>><no file info>, 0

the error reported after the failed call to VirtualAlloc is error 487:

ERROR_INVALID_ADDRESS
487     Attempt to access invalid address.

I didn't look how much the GC reserves, but i suspect it's 48 MBytes.
So the mark-compact phase isn't initiated, but the reserved space isn't 
increased
properly too (or the initial query is too small)

Original comment by prunedt...@gmail.com on 19 Jan 2007 at 8:59

[GoogleCodeExporter]

Dave,  <egg suck alert> when looking to solve this I strongly recommend *not* 
having
the VM automatically run the scan-mark garbage collectort and/or growing memory.

Instead, have the VM support a primitive to reserve some space (e.g. in typical 
usage
1 meg), modify the allocation primitives to fail and release the reserve for 
use when
memory other than this reserve has run out, and add primitive failure code for 
new,
new: et al that runs the garbage collector through a primitive from the image, 
and
then allocate more heap, again through a primitive, from the image.

Allowing the VM to run the garbage collctor at arbitrary time sin primitives 
really
complicates keeping track of pointers (and this is even more acute in a
multi-threaded VM).  Allowing the VM to grow memry puts much too much policy 
down in
the VM which makes it hard to architect server applications etc.  Keeping 
things up
in Smalltalk provides a much more reliable, extensible system </egg suck alert>.

e.g. VisualWorks keeps thigs above the line and Squeak does not.  Squeak 
primitives
are really tricky to write as a result.

Original comment by eliot.miranda@gmail.com on 9 Feb 2007 at 7:27

[GoogleCodeExporter]

I've just checked in changes to make this happen.

Based on Eliot's recommendation, the allocation primitives have been changed to 
fail
if insufficient space is available in new space for the allocation. This then 
invokes
the fail block in the Strongtalk image code.

New primitives have been added to expand and shrink object memory and the fail 
blocks
in the Strongtalk image code has been updated to make use of these. Rather than
modify the existing primitives I have added a new set of NoReceiver primitives 
which
allocate the various classes of object - non-indexable, object-indexable and
byte-indexable. These all take an additional argument - tenured - to indicate 
whether
the allocation should be attempted in newgen or oldgen.

The new primitives are called from new allocation methods on the class side of 
VM.
These methods are then called by the Behaviors that require them.

The generated versions of the New primitives (primitiveNew[0-9]) have also been
modified to fail if insufficient space is available in newgen.

I have added a companion image and sources to the download section.

For an example of the new code in action try recompile world from the File menu 
on
the launcher. I have commented out the code to explicitly call the garbage 
collection
from within the relevant method, so now you should see far fewer GCs during
recompilation. Please note that if you try this with Recompilation turned on 
then
recompile world may not complete, although it may. It works for me about 50% of 
the
time.  

Original comment by StephenL...@gmail.com on 1 Nov 2008 at 7:38

• Changed state: Fixed