Cleanup of memory on process exit

[Richard Frith-Macdonald]

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.