From: Mathieu Bouchard <matju@...>
Date: 2000-10-16T16:05:53+09:00
Subject: [ruby-talk:5572] Re: GC: malloc_memories

> |ok, malloc_memories is going to the trashcan. I'll put a counter that's
> |incremented in rb_newobj() and reset in rb_gc(). this should separate
> |completely two parts (?):

> I agree with throwing malloc_memories to the trashcan.  But I don't
> think rb_newobj() can collect appropriate information.  Only
> information it can know is number of object allocation, which is
> already detected by free list exhaustion.

Well, no, because free list exhaustion only says something about the total
number of cells, but I wish to count the number of _recently_ allocated
cells, that is, allocated since the last GC phase.

Isn't the rule that GC should be done either:

	1. when it *must* be done
	2. every once in a while

So, that counter of recently allocated cells takes care of case #2, just
like malloc_memories did.

> malloc_memories collect information about size of memory chunks
> referred from objects. 

It might be quite interesting to take into account memory chunks referred
from objects. However, unless we have a way to peek at realloc's size
difference (instead of only the new size) then realloc becomes slower than
usual, because of the GC, and this is not right.

It is true that if you are allocating bigger objects you may want to do GC
(much) more often, otherwise, big objects can exhaust memory very quickly
without the GC doing anything.

A solution is to make ruby_x*alloc perform pointer translations. we can
then insert a int-sized (or long-sized) header for the size of the
allocated chunk, so that we can retrieve that info for realloc accounting. 
This is, of course, regardless of any pre-existing accounting at the C
Library level, thanks to POSIX. :-/

What do you think? (I'm only getting used to playing with GC. never did
that before)

matju