From: Tom Tromey <tromey@redhat.com>
To: gdb-patches@sourceware.org
Subject: RFA: lazily allocate bcache obstack
Date: Tue, 05 Aug 2008 20:32:00 -0000 [thread overview]
Message-ID: <m33aljmcqt.fsf@fleche.redhat.com> (raw)
Today I was looking at 'maint print statistics' for a large program
(openoffice, with 162 shared libraries).
In the output I noticed that in many cases there was an empty bcache
of some kind, each taking around 4k.
This patch changes bcache to lazily initialize its obstack. According
to 'maint space 1', this saved 2355200 bytes on the openoffice test
case.
Built and regtested on x86-64 (compile farm).
Ok?
Tom
b/gdb/ChangeLog:
2008-08-05 Tom Tromey <tromey@redhat.com>
* bcache.c (deprecated_bcache_added): Initialize obstack.
(bcache_xmalloc): Don't initialize obstack.
(bcache_xfree): Conditionally free obstack.
diff --git a/gdb/bcache.c b/gdb/bcache.c
index 9f7a915..6235df5 100644
--- a/gdb/bcache.c
+++ b/gdb/bcache.c
@@ -231,6 +231,16 @@ deprecated_bcache_added (const void *addr, int length, struct bcache *bcache,
if (added)
*added = 0;
+ /* Lazily initialize the obstack. This can save quite a bit of
+ memory in some cases. */
+ if (bcache->total_count == 0)
+ {
+ /* We could use obstack_specify_allocation here instead, but
+ gdb_obstack.h specifies the allocation/deallocation
+ functions. */
+ obstack_init (&bcache->cache);
+ }
+
/* If our average chain length is too high, expand the hash table. */
if (bcache->unique_count >= bcache->num_buckets * CHAIN_LENGTH_THRESHOLD)
expand_hash_table (bcache);
@@ -285,10 +295,6 @@ bcache_xmalloc (void)
{
/* Allocate the bcache pre-zeroed. */
struct bcache *b = XCALLOC (1, struct bcache);
- /* We could use obstack_specify_allocation here instead, but
- gdb_obstack.h specifies the allocation/deallocation
- functions. */
- obstack_init (&b->cache);
return b;
}
@@ -298,7 +304,9 @@ bcache_xfree (struct bcache *bcache)
{
if (bcache == NULL)
return;
- obstack_free (&bcache->cache, 0);
+ /* Only free the obstack if we actually initialized it. */
+ if (bcache->total_count > 0)
+ obstack_free (&bcache->cache, 0);
xfree (bcache->bucket);
xfree (bcache);
}
@@ -457,5 +465,7 @@ print_bcache_statistics (struct bcache *c, char *type)
int
bcache_memory_used (struct bcache *bcache)
{
+ if (bcache->total_count == 0)
+ return 0;
return obstack_memory_used (&bcache->cache);
}
next reply other threads:[~2008-08-05 20:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 20:32 Tom Tromey [this message]
2008-08-05 20:35 ` Daniel Jacobowitz
2008-08-05 20:44 ` Tom Tromey
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=m33aljmcqt.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.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