Re: Cleanup of memory on process exit

[Quentin Mathé]

Le 19 juin 2011 à 12:20, Richard Frith-Macdonald a écrit :

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

Thanks :-) I'll check what's the result is valgrind.

>> 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 makes sense. At some point, Apple was planning that (see 
objc_getClassVariable() in the new runtime API), but based on what I read on 
Apple ObjC list, they have changed their mind :-(

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

libobjc2 supports associative references (and this could be added to the 
ObjectiveC2  framework). Associative references should work as a way to create 
class variables. However it's a map table lookup too (or a linked list 
traversal in libobjc2), so it's slower than real class variables.
See 
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocAssociativeReferences.html

Cheers
Quentin.