Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Gergely K. <ger...@ma...>]

Hi,

If NSAutoReleasePool is threadsafe, we could add a background thread /
timer, which drains the autoreleasepool periodically. Different applications
may require different draining strategies, so this should be manageable from
the Java side using e.g. an XMLVM specific API, like:
XMLVMSettings.setGCProvider().

In any case, we can do best of both worlds: only declare the autorelease
pools in the wrapper, where necessary, and drain the central one using the
background thread approach.

What do you think?

Best Regards,
Gergely

2010/3/29 Arno Puder <ar...@pu...>

>
> I do agree that it is generally preferable to retain the semantics of
> the JVM. Having to call explicitly System.gc() periodically would be a
> deviation of this. However, merely instantiating NSAutoreleasePool
> causes *huge* performance hit (NSAutoreleasePool is a pretty complicated
> data structure when you think about it). Instead of instantiating a new
> NSAutoreleasePool in the wrappers as Gergely suggested, I propose to
> simply drain the one NSAutoreleasePool we need to create anyways.
>
> Arno
>
>
> On 3/28/10 11:34 PM, Gergely Kis wrote:
> > Hi,
> >
> > Since the generated code AFAIK does not call any Cocoa methods directly,
> > my suggestion is that in the compat-lib we should create autorelease
> > pools in the wrapper methods to make sure that if such Cocoa methods are
> > called, the objects get into an autorelease pool in the same method.
> > Then of course one needs to do a [x retain] on return, as usual.  This
> > way the compat-lib will conform to both the Cocoa Memory Management
> > guidelines and the XMLVM calling convention.
> >
> > I planned to do this even when the generated code still used autorelease
> > pools.
> > The reason:
> > If you call a wrapper method in a tight loop, which implicitly puts
> > objects on the nearest autorelease pool in the call stack, you could end
> > up with many objects in the pool that should have been freed already,
> > before your application's Java method has the chance to free them.
> >
> > Of course I think it is advisable to use the [[alloc] init*]  sequence
> > everywhere, if you can, because of the performance benefits. However, I
> > already ran into places where the Cocoa API only provides you
> > autoreleased objects, and you have no way to request otherwise.
> >
> > I think the strategy should be to minimize the deviations from the JVM
> > based Java platforms, and making the programmers call System.gc() is in
> > my opinion a step in the wrong direction.
> >
> > Best Regards,
> > Gergely
> >
>
>

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622