Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Accuracy of Gc.stat ()
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-11-21 (16:45)
From: Damien Doligez <damien.doligez@i...>
Subject: Re: [Caml-list] Accuracy of Gc.stat ()
On Wednesday, November 19, 2003, at 06:52 PM, Daniel Bünzli wrote:

> Since my first attempt [1] didn't really get through, I try to 
> reformulate my post.

Sorry I didn't answer earlier, the traffic on caml-list is getting
quite heavy these days.

> 1) What is the accuracy of these results ?
> E.g. I read in the documentation of the Gc module that the field 
> minor_words is only an approximation in programs compiled to native 
> code.

Because of the way we trigger a minor collection in native code, the
counters will overestimate the number of words allocated by a few words
per minor GC.  Note that it is always an overestimation, and the error
is at most 256 words per collection.

>  Is it also true for the other fields ?

No.  The other fields are accurate.

>  Would the figure minor+major-promoted be accurate ?

No.  The error in minor will propagate.

>  How much can I trust the figures I get ?

You can repeat your experiment after changing the size of the
minor heap, that will give you a good idea of the error.  The
bigger the heap, the smaller the error, and it converges to
error=0 for an infinite heap.

> 2) When I start profiling should I prefer a Gc.compact to a 
> Gc.full_major ?

If you're only interested in minor+major-promoted, you don't even
need a Gc.full_major.  A Gc.compact would be if you are timing a
very allocation-intensive program, and even then I doubt it will
make much difference.

> 3) Is it possible to know at runtime whether we are running native 
> code or interpreted bytecode ?

Good question.  I don't know the answer.  Maybe you should file this
as a feature wish in the bug tracking system:
< >.

> Regarding time profiling, a binding in the Unix module to the 
> getrusage() function would definitvely be nice.

Another candidate for the bug tracking system.

-- Damien

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: