Menu
▾
▴
Re: [xmlvm-users] No dependence on NSAutoreleasePool
|
From: Arno P. <ar...@pu...> - 2010-03-28 09:13:41
|
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® 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® 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® 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® 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 >>>> >>>> >> >> |
