RFC: free pending blocks

RFC: free pending blocks

[Tom Tromey]

Another patch I've had kicking around for a while.

Currently gdb allocates pending blocks on the objfile obstack.
These aren't used once the blocks are all created, so this is just
waste.

This patch arranges to free them instead.
It also makes 'struct pending_block' private to buildsym.

Built and regtested on x86-64 Fedora 16.

Tom

2012-11-28  Tom Tromey  <tromey@redhat.com>

	* buildsym.c (struct pending_block): Move from buildsym.h.
	(pending_blocks): Likewise; now static.
	(free_pending_blocks): Free blocks.
	(record_pending_block): Use XNEW, not obstack_alloc.
	* buildsym.h (struct pending_block): Move definition to
	buildsym.c.
	(pending_blocks): Don't declare.

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 8f2e732..3acdd06 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -83,6 +83,21 @@ static struct obstack pending_addrmap_obstack;
    the end, then we just toss the addrmap.  */
 static int pending_addrmap_interesting;
 
+/* List of blocks already made (lexical contexts already closed).
+   This is used at the end to make the blockvector.  */
+
+struct pending_block
+  {
+    struct pending_block *next;
+    struct block *block;
+  };
+
+/* Pointer to the head of a linked list of symbol blocks which have
+   already been finalized (lexical contexts already closed) and which
+   are just waiting to be built into a blockvector when finalizing the
+   associated symtab.  */
+
+static struct pending_block *pending_blocks;
 \f
 static int compare_line_numbers (const void *ln1p, const void *ln2p);
 
@@ -205,9 +220,13 @@ really_free_pendings (void *dummy)
 void
 free_pending_blocks (void)
 {
-  /* The links are made in the objfile_obstack, so we only need to
-     reset PENDING_BLOCKS.  */
-  pending_blocks = NULL;
+  while (pending_blocks)
+    {
+      struct pending_block *next = pending_blocks->next;
+
+      xfree (pending_blocks);
+      pending_blocks = next;
+    }
 }
 
 /* Take one of the lists of symbols and make a block from it.  Keep
@@ -418,8 +437,7 @@ record_pending_block (struct objfile *objfile, struct block *block,
 {
   struct pending_block *pblock;
 
-  pblock = (struct pending_block *)
-    obstack_alloc (&objfile->objfile_obstack, sizeof (struct pending_block));
+  pblock = XNEW (struct pending_block);
   pblock->block = block;
   if (opblock)
     {
diff --git a/gdb/buildsym.h b/gdb/buildsym.h
index 0db96bf..b7d4a76 100644
--- a/gdb/buildsym.h
+++ b/gdb/buildsym.h
@@ -37,6 +37,7 @@ struct addrmap;
    this technique.  */
 
 struct block;
+struct pending_block;
 
 #ifndef EXTERN
 #define	EXTERN extern
@@ -177,21 +178,6 @@ EXTERN int context_stack_size;
 
 EXTERN int within_function;
 
-/* List of blocks already made (lexical contexts already closed).
-   This is used at the end to make the blockvector.  */
-
-struct pending_block
-  {
-    struct pending_block *next;
-    struct block *block;
-  };
-
-/* Pointer to the head of a linked list of symbol blocks which have
-   already been finalized (lexical contexts already closed) and which
-   are just waiting to be built into a blockvector when finalizing the
-   associated symtab.  */
-
-EXTERN struct pending_block *pending_blocks;
 \f
 
 struct subfile_stack

Re: RFC: free pending blocks

[John Gilmore]

That's a nice improvement.

Would it perhaps be better to just allocate these pending blocks
on their own obstack, so they can all be freed at once without doing
a lot of pointer walking?

(Or, deallocate them as they are walked to make the blockvector, to
improve cache locality, rather than in a separate pointer chain walk.)

I don't know how many such blocks are likely to exist in typical
programs, but I suspect there could be thousands.

	John

Re: RFC: free pending blocks

[Tom Tromey]

>>>>> "John" == John Gilmore <gnu@toad.com> writes:

John> Would it perhaps be better to just allocate these pending blocks
John> on their own obstack, so they can all be freed at once without doing
John> a lot of pointer walking?

John> (Or, deallocate them as they are walked to make the blockvector, to
John> improve cache locality, rather than in a separate pointer chain walk.)

I tend to doubt it matters much, but I'll do it anyhow.

John> I don't know how many such blocks are likely to exist in typical
John> programs, but I suspect there could be thousands.

You have to force symtab expansion to see them.
If I run 'gdb -readnow gdb', 44083 are created.
This is very artificial, though, since in normal debug sessions many
fewer symtabs are expanded.

I didn't try to measure the maximum depth of the stack.

Tom

Re: RFC: free pending blocks

[Tom Tromey]

Tom> Another patch I've had kicking around for a while.

Oops, wrong list.
I'll resend to the patch list.

Tom