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