Is it ok to "leak" modest amounts of objalloc memory?

Is it ok to "leak" modest amounts of objalloc memory?

[Bernd Jendrissek]

I am working on OMF support, and I need to do the equivalent of
realloc(3) when resizing string tables.  Using bfd_alloc() simplifies
my code greatly, as I don't have to worry about deallocating memory
when I'm done using it - relying on the call to bfd_release in my
_bfd_check_format hook.  Unfortunately there seems to be no way to
resize an existing allocation - so in effect I'd be "leaking" memory
(that is, only until the end of _bfd_check_format) on certain object
files that trigger array resizes.

Due to the nature of the target, there's not a whole lot of memory I
can leak; OMF indexes run from 1 to 65535, so the amount of memory
wasted in resizes is limited to 128KiB per category.  One could also
conceive of pathological object files that would waste many many times
this amount, by, for example, having 65535 segments, with each having
65535 relocations.  But I don't expect such files to be at all common!

With desktop systems nowadays sporting multiple gigabytes of RAM, I'm
tempted to just waste a few hundred KiB and quit worrying about it.
Besides, the wasted memory would total no more than that which is
unwasted - I'd just double the buffer size each time it runs out of
space.  How do other binutils folk feel about this sort of issue?

RE: Is it ok to "leak" modest amounts of objalloc memory?

[Paul_Koning]

>I am working on OMF support, and I need to do the equivalent of
>realloc(3) when resizing string tables.  Using bfd_alloc() simplifies my code greatly, as I don't have to worry about deallocating memory when I'm done using it - relying on the call to bfd_release in my _bfd_check_format hook.  Unfortunately there seems to be no way to resize an existing allocation - so in effect I'd be "leaking" memory (that is, only until the end of _bfd_check_format) on certain object files that trigger array resizes.

>Due to the nature of the target, there's not a whole lot of memory I can leak; OMF indexes run from 1 to 65535, so the amount of memory wasted in resizes is limited to 128KiB per category.  One could also conceive of pathological object files that would waste many many times this amount, by, for example, having 65535 segments, with each having
>65535 relocations.  But I don't expect such files to be at all common!

>With desktop systems nowadays sporting multiple gigabytes of RAM, I'm tempted to just waste a few hundred KiB and quit worrying about it.
>Besides, the wasted memory would total no more than that which is unwasted - I'd just double the buffer size each time it runs out of space.  How do other binutils folk feel about this sort of issue?

It seems like a small thing, but it also feels like a bad precedent.  How would a future maintainer know that this is a "little leak" and ok, while the exact same code cut & pasted to a different situation is not ok because there the leak is much larger?  Better to fix the underlying machinery to provide the facility you need.

	paul

Re: Is it ok to "leak" modest amounts of objalloc memory?

[Bernd Jendrissek]

On Thu, Aug 18, 2011 at 12:48 PM,  <Paul_Koning@dell.com> wrote:
> It seems like a small thing, but it also feels like a bad precedent.  How would a future maintainer know that this is a "little leak" and ok, while the exact same code cut & pasted to a different situation is not ok because there the leak is much larger?  Better to fix the underlying machinery to provide the facility you need.

Thanks for the reply.  Do you know, off the top of your head, of any
other targets that resize things?  A quick grep found carsym_mem in
vms-lib.c, but having to keep track of whether an object is on the
heap or has been objalloc'ed seems hairy in its own way!

Re: Is it ok to "leak" modest amounts of objalloc memory?

[Hans-Peter Nilsson]

On Thu, 18 Aug 2011, Bernd Jendrissek wrote:
> I am working on OMF support, and I need to do the equivalent of
> realloc(3) when resizing string tables.  Using bfd_alloc() simplifies
> my code greatly, as I don't have to worry about deallocating memory
> when I'm done using it - relying on the call to bfd_release in my
> _bfd_check_format hook.  Unfortunately there seems to be no way to
> resize an existing allocation - so in effect I'd be "leaking" memory
> (that is, only until the end of _bfd_check_format) on certain object
> files that trigger array resizes.
>
> Due to the nature of the target, there's not a whole lot of memory I
> can leak; OMF indexes run from 1 to 65535, so the amount of memory
> wasted in resizes is limited to 128KiB per category.

Having no idea what counts as a category in that context, I'll
just assume that it's typically less than ten per object file
and that you're typically not looking at more than about 128KiB
per object file; not more than 1M even for big files.  Right?

I wouldn't worry about it.  Regarding maintanance, just put a
comment above the bfd_alloc call mentioning that the memory is
not freed until <whatever>.

brgds, H-P