garbage collection

[Bulat Ziganshin]

Hello Simon,

Thursday, April 21, 2005, 1:57:20 PM, you wrote:

SM> On 20 April 2005 15:56, Bulat Ziganshin wrote:

>>>> 1) can you add disableGC and enableGC procedures? this can
>>>> significantly improve performance in some cases

SM> I see (I think).  Unfortunately currently the size of the allocation
SM> area is fixed after a GC, so you'll have to change the code in the
SM> runtime to keep allocating more blocks for the nursery.

so that it is either impossible or too hard, as i understand you?


>> 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.

SM> It might be slower because it involves extra calls to the kernel to
SM> 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! you can try yourself
included program). the real problem is that windows goes to 0'ize all
the memory it returns to our program 

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


-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: map-unmap.cpp
Type: application/octet-stream
Size: 1010 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20050422/bf7ec2d9/map-unmap.obj