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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
