This is the mail archive of the
mailing list for the GCC project.
Re: Leaking bitmap data in ree.c?
- From: Jeff Law <law at redhat dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>
- Cc: "gcc at gnu dot org" <gcc at gnu dot org>
- Date: Mon, 21 Mar 2016 10:42:18 -0600
- Subject: Re: Leaking bitmap data in ree.c?
- Authentication-results: sourceware.org; auth=none
- References: <56EC5478 dot 5080500 at redhat dot com> <20160321032339 dot GA24419 at ball>
On 03/20/2016 09:24 PM, Trevor Saunders wrote:
Yea, but it's kindof silly to force the ggc system to handle this. At
the least a bitmap_clear would return the bitmap elements to the bitmap
element cache (which should also be more efficient for the ggc system)
On Fri, Mar 18, 2016 at 01:18:16PM -0600, Jeff Law wrote:
Is it just me, or does find_removable_extensions leak bitmap data for INIT,
KILL, GEN and TMP?
It calls bitmap_initialize on all of them, but never clears the bitmaps...
Am I missing something?
See this lovely comment for bitmap_initialize_stat () which is macroed
to bitmap_initialize ()
/* Initialize a bitmap header. OBSTACK indicates the bitmap obstack
to allocate from, NULL for GC'd bitmap. */
So I think the elements for those bitmaps are just getting allocated on
the gc heap, and everything is correct though of course it would be nice
to stop using the gc there.
I'll resist the urge for now to apply RAII principles in this code, but
that'd probably a much cleaner way to think about the problem in general.