Re: [Gnustep-cvs] r33146 - in /libs/gui/trunk: Source/ TextConverters/RTF/ Tools/

[David Chisnall]

On 29 May 2011, at 06:42, Richard Frith-Macdonald wrote:

> This might need reverting ... the change from RELEASE(X) to [X drain] is 
> generally wrong as it will cause a compile to fail with a complaint about the 
> missing variable X when you build in GC mode, since  the use of the RELEASE() 
> macro implies that the pool was created using CREATE_AUTORELEASE_POOL(X), and 
> in GC mode that evaluates to an empty string and no pool is created.
> 
> Alternatively, perhaps we should deprecate the use of the 
> CREATE_AUTORELEASE_POOL macro and change its meaning so that it's always 
> equivalent to 'NSAutoreleasePool X = [NSAutoreleasePool new]' ?

This would be my preferred option.  If you compile with GS_WITH_GC mode, you 
get the same singleton autorelease pool as when you're using ObjC GC mode.  
Sending a -drain message to it will trigger an incremental collection.

> This would make sense to support mixed GC and non-GC code (I mean code 
> intended to work when linked with other code in either world) as we'd then 
> always have the pool in existence.
> One of the purposes of the macros was to avoid the overheads of 
> creating/destroying and sending messages to autorelease pools when running in 
> GC mode, but that's a consideration from many years ago when processors were 
> slower ...

On slower machines, it's probably even more of an issue.  Typically, you create 
an autorelease pool when you are about to create a lot of new short-lived 
objects, and destroy it when you are done with them.  In a GC environment, this 
triggers a collection which will clean up most of them.  On an underpowered 
machine, the reduction in memory usage is going to outweigh the cost of a 
couple of message sends by a long time.

> On another issue ... you say:
>> Also deleted some [pool release] lines just before exit() or return-from-main
>> statements.  These cause objects to be swapped in and destructors to be run 
>> to
>> no benefit (the OS will reclaim this memory without requiring stuff to be
>> swapped in when the process exits).
> 
> I seem to remember this philosophical point being raised before on the 
> mailing lists, and someone saying that this was a bad thing to do.
> Yes, skipping 'cleanup' on program exit is more efficient, but are machines 
> really so slow that this is an issue?  

Yes.  The key issue is swapping.  The long-lived objects in the top-level 
autorelease pool are the ones most likely to be swapped out.  When you swap all 
of these in, typically something else has to be paged out, and this is 
something that the user is infinitely more likely to want to use again soon 
(because they have 0 chance of actually wanting to use a free'd object soon).  
On large OS X applications, you can fire up instruments and see them spending 
several seconds hitting the disk hard (very irritating when you're using flash 
for swap space) when they exit.  And then several minutes watching your other 
applications become less responsive because they periodically have to swap 
things back in that were swapped out to make space for the autoreleased objects 
being swapped back in.  Oh, and you can also watch your battery life drop, 
since now your disk has to stay spun up for several minutes as a result of 
quitting a program...

Freeing the autorelease pool also hides bugs where objects require -dealloc to 
be called for graceful termination, which will break things like sudden 
termination support.  

David