garbage collection

[Simon Marlow]

On 22 April 2005 13:26, Bulat Ziganshin wrote:

>> I see (I think).  Unfortunately currently the size of the allocation
>> area is fixed after a GC, so you'll have to change the code in the
>> runtime to keep allocating more blocks for the nursery.
> 
> so that it is either impossible or too hard, as i understand you?

Neither, it just means someone has to write some code :-)

>>> i don't see resons why this can be slower. we will be a "good
>>> citizens" - return memory what is not used at current moment and
>>> reallocate memory when needed.
> 
>> It might be slower because it involves extra calls to the kernel to
>> free/allocate memory, and the kernel has to update its page tables.
> 
> it is very fast, at least in my win xp (120 thousands of 1-mbyte
> blocks are unmapped/mapped in one second!

That doesn't sound too fast to me...

> so, the best solution, i think, will be current one + madvise for
> systems that supports it + one small but major change: current code
> switches to compacting when more than 30% of
> RtsFlags.GcFlags.maxHeapSize is used. it must calculate 30% of
> PHYSICAL memory while maxHeapSize is developed to limit VIRTUAL memory
> usage

I don't understand that comment... there's no difference between
physical and virtual memory outside the kernel.

Cheers,
	Simon