Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Slow GC problem
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Shivkumar Chandrasekaran <shiv@e...>
Subject: Re: [Caml-list] Slow GC problem

I took Damien's advice (thanks) and spent some time trying to re-use 
all the bigarrays I was allocating. However, my bigarray use is spread 
out over a fairly complicated algorithm, and the only way to make a 
good dent on  bigarray use would be to completely rewrite the algorithm 
in a more traditional fortran77 style. Which would of course mean that 
I would have to first figure out the entire memory usage pattern.

...... So I am pondering another solution:

What if I modified bigarray_stubs.c to use the malloc and free calls of 
the Boehm gc (6.1-4) garbage collector? My reasoning is that malloc is 
performing poorly due to fragmentation, and switching to a gc'd version 
might help out.

Before I try this I would like some feedback from the list on the 
soundness of this idea. Thanks,

--shiv--

On Tuesday, April 8, 2003, at 03:23 AM, Damien Doligez wrote:

>> I have a gc efficiency problem for which I require some advice. I 
>> have read both the O'Reilly book and the manual on gc.
> [...]
>>  Below I give the gc stats just before and after the solver routine 
>> is called in the in-core solver:
>>
>> 				"Just before"	"Just after"
>> minor_words:		46243376	139259767
>> promoted_words:	928267		2595523
>> major_words:		2883087		39489766
>> minor_collections:	1412		4591
>> major_collections:	18			52
>> heap_words:		2150400		1044480
>> heap_chunks:		35			17
>> top_heap_words:	2150400		5038080
>> live_words:		1842373		840037
>> live_blocks:		253926		116816
>> free_words:		307180		204440
>> free_blocks:		47368		17
>> largest_free:		10928		61440
>> fragments:		847			3
>> compactions:		0			2
>
> As others have said, this is not really enough information to tell
> what is going on.  What we can say from the above is:
>
> 1. You are allocating lots and lots of data structures in the major
>    heap (maybe finalized bigarray descriptors)
> 2. The compactor was called twice, which may indicate that you have
>    a fragmentation problem.
> 3. The compactor was called near the end of the solver routine,
>    which must have erased most of the evidence...
>
> -- Damien
>
--shiv--

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners