[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cleanup of memory on process exit
From: |
Richard Frith-Macdonald |
Subject: |
Cleanup of memory on process exit |
Date: |
Sun, 19 Jun 2011 11:20:25 +0100 |
On 18 Jun 2011, at 12:48, Quentin Mathé wrote:
> Le 18 juin 2011 à 09:41, Richard Frith-Macdonald a écrit :
>
>> On 17 Jun 2011, at 11:39, Quentin Mathé wrote:
>>>
>>> However what I observe is that valgrind reports many memory leaks, even
>>> with a progam that does nothing (see code below), and this means it's hard
>>> to track down a memory corruption with valgrind. The output becomes really
>>> huge (several MB) when you run a real application or tool.
>>>
>>> #import <Foundation/Foundation.h>
>>>
>>> int main (int argc, const char * argv[])
>>> {
>>> CREATE_AUTORELEASE_POOL(pool);
>>> DESTROY(pool);
>>> return 0;
>>> }
>>>
>>> Here is the valgrind output with 'valgrind --leak-check=full' for the
>>> progam above: http://60gp.ovh.net/~dromasof/gnustep/base-valgrind.log
>>
>> Yeah ... we create a load of data structures and cache a load of stuff, all
>> of which is fine and right for performance, but that *does* make it harder
>> to sport real leaks.
>> I've toyed with the idea of providing a standard mechanism to register
>> objects in some way rather than storing them in static variables, so we
>> could (when in debug mode) release all such registered objects from an
>> atexit handler. Of course, going through all the codebase and changing all
>> the deliberately 'leaked' data to be registered that way would be a large
>> undertaking for no operational gain ... but the advantage for tracking leaks
>> is big enough that I'd be prepared to devote some time to it.
>
> I think that would be great.
I've experimentally implemented some new stuff in svn trunk to allow us to
clean up long-term data structures owned by classes when the process exits.
> Also if there is a such standard mechanism to know which "static" variables
> are associated to which class, this makes possible to create multiple
> instances of a class at runtime. I think that could open up interesting
> possibilites with Étoilé's LanguageKit. For example, class hierarchy
> inheritance becomes possible (you just copy a class and its subclasses) and
> we could implement features like modules in a new language (for example, see
> http://bracha.org/newspeak-modules.pdf).
That seems link a whole new problem for which we'd need extra runtime support
... the class structure in the runtime would have to have a pointer to
associated class variables.
Yes we could do class variables via a map table lookup, but that would be slow,
and very often the reason for classes using static variables is for fast access
to things.
I've used a trick to implement class variables in some of my code ... using the
class version to index into a table of pointers to variables ... but that's
really an evil hack of a misuse of the class versioning system and clearly can
only be used for classes which don't use the versioning mechanism normally (and
where subclasses won't mess with it). I could make the code public if you
really want, bit it is pretty evil really.
- Please test pending bugfix release of base, Richard Frith-Macdonald, 2011/06/16
- Re: Please test pending bugfix release of base, Quentin Mathé, 2011/06/18
- Cleanup of memory on process exit,
Richard Frith-Macdonald <=
- Re: Cleanup of memory on process exit, Quentin Mathé, 2011/06/19
- Re: Please test pending bugfix release of base, Ivan Vučica, 2011/06/18
- Re: Please test pending bugfix release of base, Sebastian Reitenbach, 2011/06/18
- Re: Please test pending bugfix release of base, Richard Frith-Macdonald, 2011/06/18
- Re: Please test pending bugfix release of base, David Chisnall, 2011/06/18
- Re: Please test pending bugfix release of base, Richard Frith-Macdonald, 2011/06/18
Re: Please test pending bugfix release of base, Quentin Mathé, 2011/06/18
Re: Please test pending bugfix release of base, Sebastian Reitenbach, 2011/06/19