On Mon, Jan 09, 2012 at 12:33:49AM +0200, Török Edwin wrote:
On 01/08/2012 09:00 PM, Richard W.M. Jones wrote:
Probably the OCaml GC should be setting madvise hints anyway.
It should mmap()/munmap() instead of malloc/realloc/free in that
case, right? Which probably wouldn't be a bad idea, as
On Sun, Jan 08, 2012 at 06:45:05PM +, Richard W.M. Jones wrote:
And that brings us to (c): does it even make sense to give back memory
to the OS?
I forgot to mention one way in which this is more efficient: If you
munmap a piece of memory and later decide you need more memory so you
call
Thank you for the detailed response Rich.
Isn't the goal of compaction to keep all of these blocks of memory as close as
possible? I should have noted the fragmentation of my heap after compaction,
but it seems unlikely that my 1meg of actual data could be fragmented across
400megs worth of
Hello everyone!
I would like to reassure you that all is right in the world. After a large
number of tests I finally tracked the problem down to an entry in a Hashtbl not
being deleted. It was a one line fix!
One question does remain though: In my tests I would do some work that would
cause
On 2012-01-01, at 13:44, Richard W.M. Jones wrote:
Is compaction disabled? lablgtk disables it unconditionally by
setting the global Gc max_overhead (see also the Gc documentation):
src/gtkMain.ml:
let () = Gc.set {(Gc.get()) with Gc.max_overhead = 100}
Anyone who disables
There is however something to do. Quoting lablgtk's README:
IMPORTANT: Some Gtk data structures are allocated in the Caml heap,
and their use in signals (Gtk functions internally cally callbacks)
relies on their address being stable during a function call. For
this reason automatic
Being on the C side is not even something I had considered. In this case, I
think the only piece of code not part of the Ocaml RTS that is talking to C is
Lwt. It is possible that there is a memory leak in there somewhere. The
upside, though, is there seems to be some residue of it in the
I am running a fork of mfp's ocamlmq. I am trying to track down an apparent
memory leak, after a week of heavy usage the process is using up 2GB of RAM,
and after looking in all the obvious places (all of the containers tracked in
the state object in the mq appear to be empty or steady in
