Re: [xmlvm-users] No dependence on NSAutoreleasePool

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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

>
> it is actually interesting to note that Cocoa places quite a few objects
> in the autorelease pool. If you comment out the creation of the one
> autorelease pool in XMLVM's main() method, you will get a lot of
> warnings of leaking objects. Since XMLVM no longer places objects in the
> autorelease pool, these must come from Cocoa. As a matter of fact, all
> so-called convenience methods where the object is not created via the
> usual alloc/init (e.g., [NSString string*]), are placed by convention in
> an autorelease pool. So the question is how to deal with that in XMLVM.
> One suggestion would be to implement System.gc() so that it calls [pool
> drain]. It would be the programmers responsibility to call System.gc()
> from time to time.
>
> In case of the enumerator, since we know it is placed in the autorelease
> pool, one could do a [pool drain] in the wrapper.
>
> Any other ideas?
>
> Arno
>
>
> On 3/28/10 1:21 AM, Joshua Melcon wrote:
> > Thanks for the project -- it was very easy to get running.  After some
> > investigation, it looks like the call to NSMutableArray
> > objectEnumerator causes an object to be allocated in the auto release
> > pool.  I verified it by experiment, but it also looks to be how the
> > NSCollection classes work:
> >
> >
> http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m
> >
> > - (NSEnumerator*)objectEnumerator
> > {
> >      return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc]
> >                             initWithDictionary:self]);
> > }
> >
> > The reference code is doing its job perfectly.  The NsMutableArray is
> > also OK. Eventually, if the thread terminated it would cause all the
> > itereators that were added to the autorelease pool to be freed.
> > Basically the call stack is:
> >
> > run thread // creates an auto release pool, releases after its callees
> > come back.
> > ...
> > loop forever creating iterators in the auto release pool, effectively
> > never freeing the memory the iterators used.
> >
> > I am too tired to think of a clever solution at the moment, but I will
> > look at it tomorrow.  If you want a workaround, just use a for loop
> > rather than an iterator in that thread :/
> >
> > It seems somewhat weird that the enumerators work this way in obj c,
> > because it creates this probably in normal objective c... Course its
> > nice to not have to worry about freeing enumerators....
> >
> > -- Joshua Melcon
> >
> >
> >
> > 2010/3/27 Paul Poley<bay...@gm...>:
> >> Sure thing.  I've attached an Eclipse project.  It starts the UI&  then
> runs
> >> a background thread, which infinitely loops.  Inside the loop, a method
> is
> >> called so that anything allocated can be released, which wouldn't
> otherwise
> >> happen until the loop ended (that fact is unrelated to our discussion).
> >> Inside the method, an ArrayList is allocated&  iterated.  Nothing is
> >> actually added to it.
> >> When compiling against revision 977, memory usage remains consistent.
>  When
> >> compiling against revision 981, memory usage is quickly increased.  I
> use
> >> the OSX "Activity Monitor" to check memory usage.
> >> Thanks Josh!
> >> Paul Poley
> >>
> >>
> >> 2010/3/27 Joshua Melcon<xm...@me...>
> >>>
> >>> Hi Paul,
> >>>
> >>> I attempted to produce a leak with the array list iterator today using
> >>> a few variations of code similar to:
> >>>
> >>> ArrayList<InternalClass>  a = new ArrayList<InternalClass>();
> >>>                 for(int x=0;x<10000;x++)
> >>>                 {
> >>>                 a.add(new InternalClass());
> >>>                 }
> >>>                 for(InternalClass x:a)
> >>>                 {
> >>>                         x.toString();
> >>>                 }
> >>>
> >>> I am unable to see any leaking objects.
> >>>
> >>> Additionally, I inspected the array list iterator code -- it seems
> >>> work when I step through it.
> >>>
> >>> In order to debug this issue I think that I need some help from you.
> >>> If you could create a self contained example that causes a memory leak
> >>> I would be more than happy to figure out what is going on.
> >>>
> >>> Thanks,
> >>>
> >>> -- Joshua Melcon
> >>>
> >>>
> >>>
> >>> 2010/3/27 Paul Poley<bay...@gm...>:
> >>>> Hi All,
> >>>> I was just making some suggested modifications to a couple of my
> >>>> patches.
> >>>>   After I was done, I was testing to make sure I didn't introduce any
> >>>> memory
> >>>> leaks.
> >>>> Unfortunately, the code seemed to have a lot of leaks.  Upon digging
> in,
> >>>> the
> >>>> first leak I found was in ArrayList's iterator(), which didn't leak
> >>>> before&
> >>>> nothing had changed (side note: that existed before my patches).  When
> I
> >>>> first tested&  submitted my patches, they were using the auto-release
> >>>> pool.
> >>>>   So I reverted to revision 977 before the auto-release pool was
> removed
> >>>> &
> >>>> all the leaks went away.
> >>>> Has anyone else observed a similar effect?  For now I will need to
> >>>> continue
> >>>> using the old version.
> >>>> Perhaps we can set up a branch separate from trunk that removes the
> >>>> auto-release pool until it's been fully baked?
> >>>> Thanks a bunch!  I appreciate the effort!
> >>>> Paul Poley
> >>>>
> >>>> 2010/3/26 Arno Puder<ar...@pu...>
> >>>>>
> >>>>> I just committed Joshua's fix.
> >>>>>
> >>>>> Arno
> >>>>>
> >>>>>
> >>>>> On 3/25/10 10:49 PM, Joshua Melcon wrote:
> >>>>>> Ok, I understand now.  Yes that is a bug -- and an interesting one.
> >>>>>> Basically, its doing:
> >>>>>>
> >>>>>>
> >>>>>> R1 = object;  // R1 has one retain
> >>>>>> Temp = R1; /
> >>>>>> R1 = object.subobject
> >>>>>> Release Temp (causing an implicit release of the object now in R1)
> >>>>>> retain R1 (so we don't lose it).
> >>>>>>
> >>>>>> Basically, the fix is to just emit the retain instruction before the
> >>>>>> rtmp release.  In the future, we will notice that the back to back
> >>>>>> retain/release is not necessacry.
> >>>>>>
> >>>>>> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it
> >>>>>> to
> >>>>>> the trunk after the review completes.
> >>>>>>
> >>>>>> Panayotis: Thanks for finding the bug! I appreciate the feedback, as
> >>>>>> well as your clear description of the issue and how to reproduce it.
> >>>>>> Please let me know if you find anything else.
> >>>>>>
> >>>>>> all :)
> >>>>>> -- Joshua Melcon
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
> >>>>>> <pan...@pa...>    wrote:
> >>>>>>> Yes these applications work.
> >>>>>>>
> >>>>>>> If you just try to convert the java source code I gave to you
> >>>>>>> though,
> >>>>>>> you
> >>>>>>> will see the error :)
> >>>>>>> Just try ;)
> >>>>>>> To be fair, I've also checked a lot of code, from my own
> >>>>>>> appplications
> >>>>>>> and
> >>>>>>> test cases and this was the only problem found :)
> >>>>>>>
> >>>>>>> Still, it is a bug ;)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Panayotis
> >>>>>>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>
>  έγραψε:
> >>>>>>>
> >>>>>>> If the last retain is failing it indicates that there is an issue
> >>>>>>> related to
> >>>>>>> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
> >>>>>>>
> >>>>>>> I have run Xokoban, Afireworks, and another CCed program and not
> >>>>>>> encountered
> >>>>>>> any problems.  It is possible that you have found a case which we
> do
> >>>>>>> not
> >>>>>>> handle correctly that doesn't show up in those programs.  Later
> >>>>>>> tonight
> >>>>>>> I
> >>>>>>> can attempt to reproduce this error using one of our demo apps --
> >>>>>>>
> >>>>>>> Could you confirm that the Xokoban and Afireworks demo apps are
> >>>>>>> working
> >>>>>>> for
> >>>>>>> you?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>>
> >>>>>>> -- Joshua Melcon
> >>>>>>>
> >>>>>>>
> >>>>>>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
> >>>>>>>>
> >>>>>>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
> >>>>>>>>
> >>>>>>>>>      _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; //
> R2
> >>>>>>>>> comes
> >>>>>>>>> back ref count += 1 because its a get function
> >>>>>>>>>      _rtmp.o =  _r2.o; // We are overwriting R2 on the next line,
> >>>>>>>>> so
> >>>>>>>>> we
> >>>>>>>>> need to free our +1 afterwords
> >>>>>>>>>      _r2.o = ((org_xmlvm_iphone_CGRect*)
> >>>>>>>>> _r2.o)->size_org_xmlvm_iphone_
> >>>>>>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
> >>>>>>>>>      [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the
> +=
> >>>>>>>>> from
> >>>>>>>>> the first line
> >>>>>>>>>      [_r2.o retain]; // retaining the value from _r2, presumably
> >>>>>>>>> because
> >>>>>>>>> we will be returning soon (can't tell without the rest of the
> >>>>>>>>> code).
> >>>>>>>>>
> >>>>>>>>> But, based on this code sequence, everything looks correct?  How
> >>>>>>>>> does
> >>>>>>>>> _r2.o retain break things?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> It says that it tries to retain am already fee'd object.
> >>>>>>>>
> >>>>>>>> Try it for yourself and see ;)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ------------------------------------------------------------------------------
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> 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
> >>>>
> >>>>
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> 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
>

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