Leaking bitmap data in ree.c?

[Trevor Saunders]

On Mon, Mar 21, 2016 at 10:42:18AM -0600, Jeff Law wrote:
> On 03/20/2016 09:24 PM, Trevor Saunders wrote:
> >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.
> 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)

yeah

> 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.

I worked on a couple attempts to c++ify bitmaps a while back, but never
finished any of them, but I could probably publish what I did in case
someone wants to pick that up for gcc 7.

Trev

> 
> jeff