unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: cell heap usage in 1.8 vs 1.6
Date: Tue, 21 Aug 2007 00:16:42 +0200	[thread overview]
Message-ID: <87lkc5q2b9.fsf@chbouib.org> (raw)
In-Reply-To: 87ir7ff1ho.fsf@zip.com.au

Hi Kevin,

Kevin Ryde <user42@zip.com.au> writes:

> I'm having trouble in my charting program with the amount of heap space
> allocated for cells in 1.8.  It ends up allocating more and more heap
> (as reported by gc-stats 'cell-heap-segments and confirmed by
> mallinfo()), apparently without bound.  I've got between 150k and 200k
> objects according to gc-live-object-stats, which should be about 5Mb of
> cells, but the heap keeps growing to as much as 60Mb.

Did you try running it with HEAD?  There were small GC-stats "cleanups"
committed there that are not in 1.8, so it may be worth trying.

Besides, is your Guile compiled with `-O2'?  If not, it could be the
case that large amounts of stack space are used, but not always
overwritten, which erroneously leaves references to otherwise
unreferenced objects on the stack.  (That is unlikely to explain the
whole phenomenon, though.)

> Should the collected counts end up basically as "heapsize - liveobjects"
> every time?

I think so.

> They seem to be smaller than that, but I don't know where
> to look for how or why.  scm_i_sweep_segment() looks slightly doubtful.
> Does it deliberately not count the balance of a lazy sweep towards the
> collected counts?

Sorry, I don't understand what you mean here.

> I wondered if a gc is provoked by the double cells
> being exhausted but only a little of the single cells having been
> collected, leaving a small collected count in the latter (or vice
> versa).

I dunno.  At any rate, `(gc)' calls `scm_i_sweep all_segments ()', so
this should allow you to test this hypothesis.

Also, did you try fiddling with the `GUILE_MIN_YIELD_{1,2}' variables?

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2007-08-20 22:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-17  0:28 cell heap usage in 1.8 vs 1.6 Kevin Ryde
2007-08-20 22:16 ` Ludovic Courtès [this message]
2007-08-23  0:58   ` Kevin Ryde
2007-08-23  8:37     ` Ludovic Courtès
     [not found]       ` <878x7vb64r.fsf@zip.com.au>
2007-08-29 11:36         ` Ludovic Courtès
2007-10-08 14:00 ` Ludovic Courtès
2007-10-10  9:30 ` Ludovic Courtès
2007-10-12 10:08   ` Ludovic Courtès

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

  List information: https://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87lkc5q2b9.fsf@chbouib.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).