From: Han-Wen Nienhuys <hanwen@cs.uu.nl>
Cc: guile-devel@gnu.org
Subject: substantial performance loss when running long-lived or computationally intensive programs
Date: Wed, 14 May 2003 13:14:14 +0200 [thread overview]
Message-ID: <16066.9478.131532.331041@localhost.localdomain> (raw)
In-Reply-To: <20030505.223626.84190828.wells@email.mot.com>
michaelawells@motorola.com writes:
> The Guile interpreter comes to a near halt after making a sufficiently
> large number of calls to guile built-ins which do not appropriately
> maintain the 'scm_mallocated' variable (declared in "libguile/gc.c").
> There appears to be a widespread misunderstanding as to how
> 'scm_mallocated' should be maintained.
>
> There is no comment in "libguile/gc.c" which describes what
> 'scm_mallocated' should contain, but by looking through the code, it
> appears that 'scm_mallocated' should correspond to the total number of
> bytes obtained through malloc currently held by the interpreter.
Your analysis is probably correct (I didn't check in detail), but I'm
not sure if it would be a good idea to fix all of the instances. It
would touch a lot of code for a stable release. The things you found
are fixed in 1.7.
> As 'scm_mallocated' approaches 2^32, the value of 'scm_mtrigger' may be
> set to a value _intended_ to be higher than 'scm_mallocated', but ends
> up wrapping around to a value lower than 'scm_mallocated'.
> It is also possible that 'scm_mallocated' will wrap around as well.
I've added checks in scm_gc_register_collectable_memory() in HEAD to
catch these corner-case mistakes. (This fix might be eligible for
backporting to 1.6, although they are probably moot when the other
problems you indicated aren't fixed).
One thing that does nag me, is code in srcprop.c that manipulates
scm_mallocated directly and doesn't call
scm_gc_register_collectable_memory(). Is there a good reason for this?
--
Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
next prev parent reply other threads:[~2003-05-14 11:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 3:36 substantial performance loss when running long-lived or computationally intensive programs Michael A. Wells
2003-05-14 11:14 ` Han-Wen Nienhuys [this message]
2003-05-14 14:36 ` Mikael Djurfeldt
2003-05-15 23:10 ` Han-Wen Nienhuys
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=16066.9478.131532.331041@localhost.localdomain \
--to=hanwen@cs.uu.nl \
--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).