Re: [xmlvm-users] AutoReleasePools

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

Kevin Glass wrote:
> We're currently using the java to iphone objc library and finding 
> performance issues with the default option of having an AutoReleasePool 
> for every class/method. We're focusing on games at the moment so we're 
> finding that the only class we want the pool in is the main class 
> managing the game loop and then applying the annotation 
> NoAutoReleasePool to every other class to let auto the garbage 
> management happen on the release at the end of the game loop.

Right now we only support the annotation NoAutoReleasePool that can only 
be added to methods. I was thinking of introducing more annotations 
where you could set a default setting for a whole class. Requires some 
work, but certainly might be more convenient.

> Is it advised to have so many auto release pools since they seem to have 
> a high performance overahead.

Giving every method its own auto release pool certainly introduces high 
overhead. Let me digress a little and write about the implication of 
using the NSAutoReleasePool for garbage collection. It should be clear 
that we cannot identify circular data structures with this, since the 
reference count never drops to 0 in this case. I don't see this as a 
problem, but you need to be aware of this when designing your data 
structures.

But there is another problem that we cannot deal with in a good way. 
Imagine the following code:

void foo()
{
     for (int i = 0; i < 10000000; i++)
         new String();
}

When this code gets cross-compiled, those 1000* objects would all end up 
in the auto release pool of method foo. Those objects would only get 
deleted when you exit foo. A normal garbage collector would of course be 
able to reclaim memory while the for-loop still executes. These are some 
implications for using the NSAutoReleasePool and not have a full-fledged 
garbage collector.

Coming back to your question: of course it is a huge overhead of adding 
an auto release pool to every method and in many cases, it is not really 
necessary (e.g., when no objects are being allocated inside a method). 
The problem is, that this cannot really be easily determined 
automatically. What if a method (that itself does not instantiate 
objects) calls another method (that does instantiate objects)? Perhaps 
there are some good heuristics that can be implemented inside of XMLVM, 
but for the moment we take the easy way of letting the developer give 
'hints' via the NoAutoReleasePool annotation.

Suggestions are welcome!

> Still going great here tho :) (Patch is in progress again)

:-)

Arno