1.8.6 gc.c thoughts

After examining how the 1.8.6 gc works, I had a few thoughts:

It seems that on a 'cpu intensive' program (one that generates a lot of
discardable objects--quite common), there is a competition between two
aspects of gc to call garbage_collect first (just making sure I understand
this).  They are:

1) If you run out of available heap slots, it calls garbage_collect, and if
"FREE_MIN" slots now exist (by default 4096) then it does nothing
2) If you reach GC_MALLOC_LIMIT of malloc'ed bytes, then it calls
garbage_collect.

Anyway so what happens in today's implementations is that number 1 is called
often (I believe) preventing number 2 from ever even springing, as it resets
the current count of malloc'ed bytes.  It's like garbage_collect is trying
to serve 2 masters.  I see this as curious as it basically disallows
GC_MALLOC_LIMIT from being reached, which is not what you would expect.
To fix (should it be considered a problem) I would suggest that if you run
out of heap slots available you call garbage collect AND increase the heap
(so that next time you won't run out).  Maybe don't increase the heap stack
increase size by as much as 1.8 as it now is--maybe less :)

Thoughts?

On another point, I have a question on this line of code, run at the end of
garbage collection:
if (malloc_increase > malloc_limit) {
    malloc_limit += (malloc_increase - malloc_limit) * (double)live / (live
+ freed); // this line
    if (malloc_limit < GC_MALLOC_LIMIT) malloc_limit = GC_MALLOC_LIMIT;
 }

I haven't checked this, but it seems to me that It seems to me that
(malloc_increase - malloc_limit) will always be a very small number (?)
which may not be what was expected.  I could be wrong.  In reality I think
what it should best do is
malloc_limit = GC_MALLOC_LIMIT *
percent_of_recent_allocated_memory_that_was_freed // allow the malloc_limit
to change dynamically, maybe with a fixed maximum.  I could code it up.

Anyway just bouncing back some thoughts.
Ruby rox.
-- 
-Roger Pack