Re: [xmlvm-users] General questions wrt. Java iPhone development with XMLVM

[Arno P. <ar...@pu...>]

On 1/21/11 12:25 PM, Panayotis Katsaloulis wrote:
>
> On Jan 21, 2011, at 9:46 PM, Arno Puder wrote:
>
>>
>> You are right: so-called convenience methods in Cocoa place the
>> newly-created object automatically in the autorelease pool. You can see
>> above that we create a temporary autorelease pool that we release again
>> immediately. When the GC reclaims the C version of UIButton, it will
>> call a finalizer (the __DELETE_* functions) that will do a 'release' in
>> the wrapped Objective-C UIButton.
>
> Isn't expensive to have an autorelease pool for every possible  convenience selector of ObjC?
> (not only constructors...)

Autorelease pools are expensive, yes. Please note that we already do 
exactly the same thing in the Objective-C backend because the reference 
counting algorithm used there does not know about autorelease pools. So, 
this is not a specific problem of the C backend, but a general problem.

> Apart from that, since there *are* times that GC won't collaborate perfectly with autoreleased objects (like the situation I mentioned before with delayed animations ), is there a "backup plan" in the C backend to handle and fine tune the current  memory management? (i.e. by using something like retain/release) ?

I don't know about the delayed animation API, but I'm sure it can be 
handled. It might also be possible to be more efficient with the 
creation of autorelease pools, but I first want to have a working C 
backend before starting with optimizations.

Arno