caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Chris Hecker <checker@d6.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Str memory leak in 3.06?
Date: Thu, 24 Apr 2003 15:09:55 +0200	[thread overview]
Message-ID: <20030424150955.C5587@pauillac.inria.fr> (raw)
In-Reply-To: <4.3.2.7.2.20030424001900.037a2958@localhost>; from checker@d6.com on Thu, Apr 24, 2003 at 12:41:14AM -0700

> This program leaks 10mb/sec on my machine with ocamlopt 3.06 (msvc, xp).
> 
> let _ =
>    while true do
>      let re = Str.regexp "foo" in ()
>    done;
>    ()
> 
> Inserting a call to Gc.compact in the loop doesn't affect it (well, it 
> slows the loop down a bit so the leak rate drops :).
> 
>  From a brief trip in the debugger and a glance at strstubs.cpp it appears 
> the custom finalizer is being called.  I didn't grovel in the actual regex 
> code to see where the leak was (assuming it's not my bug and I'm supposed 
> to free the regex somehow in caml code).

No, there is no need for explicit deallocation of regexps.  Actually,
there is no leak either: if you put a call to Gc.major() in the loop,
memory usage remains constant. 

What happens is that the speed of the (incremental) major collector
isn't appropriately adjusted, so it runs too slowly and lets "floating
garbage" accumulate.  This is a common problem with Caml objects that
are just handle on resources allocated outside the Caml heap: precise
determination of the space consumption of the latter is generally
impossible, causing the incremental major GC to run often too slowly,
sometimes too fast...

> I also notice that the strstubs.c has the same problem I reported in 
> bigarray (and that was fixed, bug #601) about using stat_alloc() to 
> allocate but free() to deallocate, so it should probably be fixed here as 
> well, assuming Str is going to live much longer.

The new implementation of Str that will go in release 3.07 allocates
all its data in the Caml heap, so this fixes both the issue you
mention and the "floating garbage" problem described above.

Best wishes,

- Xavier Leroy

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


  reply	other threads:[~2003-04-24 13:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-24  7:41 Chris Hecker
2003-04-24 13:09 ` Xavier Leroy [this message]
2003-04-24 23:21   ` Chris Hecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030424150955.C5587@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).