Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Paul P. <bay...@gm...>]

I have two concerns:
1) Having to worry about garbage collection at all
2) If garbage collection is based solely on time, it'd be quite difficult to
determine when to run it.  If I have an application that has usage ups &
down, I have to tune the garbage collector to run quickly enough for the
"ups".  So even during down time, I'm going to be running the garbage
collector too frequently.  Either way, the performance will still be
lackluster.  It'd be hard to write a garbage collector as smart as Java's.

What if we had a cross-compile-time option which defaults to using
NSAutoReleasePool?  If the option is overridden, it would use the solution
we're working on now.  If that's possible, it makes it easy to polish the
new solution, and gives options.

Another less ideal solution would be to discontinue using native standard
libraries such as NSMutableArray.  That would give us control to never use
"autorelease", but doesn't seem like the best idea & this would of course
cause extra work.

I would love to see XMLVM reach a maturity where we it can take any back-end
Java code (and much of front-end UI code), convert it flawlessly without
modifying the original source & not look back (especially for Android apps).

What does everyone think about the cross-compile-time option for memory
management type?

Thanks,
Paul Poley


On Mon, Mar 29, 2010 at 6:06 AM, Gergely Kis <ger...@ma...>wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>