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