Re: GNUstep, Valgring and Memory leaks.

[Nicola Pero]

> I know that there are also situations where there are intentional leaks ...
> ie. where memory is deliberately leaked because freeing it is difficult for
> some reason, and the leak should not be a problem.  For instance,
> libobjc (part of gcc rather than gnustep) does this when changing class
> lookup tables ... so that it can avoid having to lock protect all code using
> the tables in a multi-threaded environment.  The leaked version of the
> table is there so that another thread which happens to be using the
> table at the point when it is updated will be able to continue correctly
> without crashing.  The only reason this is not utterly horrible is that
> these tables are only rarely changed.  It would be better if this leak was
> fixed, but it's not seen as high priority by the gcc maintainers.

Good explanation

The leak is there because it's impossible to fix it ... unless you add
locking, which would slow down things considerably (the whole point of all
the design of this stuff is precisely to avoid locking).

It's a trade-off -- you could either use locks, or accept that you might
be going to waste (once) a little bit of memory per process.  By a little
bit I mean something between a few hundreds to a few thousands bytes, I
don't remember how the tables are sized, but it's not more than that, and
it's normally going to happen only at startup when you load all the
classes.  If you load dynamically more classes again later, it might
happen again, but it's very rare unless you're dynamically loading
thousands of classes.

Nowadays those few hundreds/thousands bytes leaked once at startup (or
potentially when a very large framework or library is loaded) are nothing,
while locking/unlocking every time you access any of those tables, for the
whole process execution, can affect speed considerably.

If someone is so worried about a those bytes of memory, I suppose libobjc
could have a compile-time option to turn on locking and deallocating
memory properly once the tables are extended.  That might be useful for
embedded systems or systems where RAM/memory is really tight.  It makes no
sense on a PC, where you definitely want to avoid the locking, as that
will give you measurable speed-ups, while you don't care about a few
hundred lost bytes at startup which has no impact whatsoever on your
application.

Anyway, yes I suppose that might be a "fix", it could be done, but I
wouldn't recommend anyone using it. :-)