Implemented in r43939. Note that the GC already has an upper bound on the size of pools: POOL_MAX_BYTES in src/gc/gc_private.h. When this exceeds the 1 MB maximum in the GC now, the GC will run every time Parrot runs out of free headers.

According to reports, Microsoft's XNA framework uses the amount of memory allocated as a guide to run full GC. Every time they've allocated a megabyte, they run the GC. We can do something similar.

Modify the "get more objects" function to:

• check the amount of memory allocated since the last GC run
• if it's less than a threshold value (defined as a C constant), allocate a new pool
• if it meets or exceeds the threshold, run a full GC

Modify the "allocate a new pool" function to:

• add the size of the new pool to the "memory allocated since last full GC"

Modify the "run full GC" function to:

• reset the "memory allocated since last full GC" counter to zero

Find an appropriate storage location for the "memory allocated since..." counter in the GC structure somewhere.

Depending on memory growth, we may need also to set a maximum memory size for Parrot to avoid unbounded growth... but that relies on us being able to detect when the internal memory overhead (highly recursive calls, for example) is significant.