Menu
▾
▴
Re: [xmlvm-users] No dependence on NSAutoreleasePool
|
From: Arno P. <ar...@pu...> - 2010-03-29 09:27:28
|
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 > > 2010/3/28 Arno Puder <ar...@pu... <mailto: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... > <mailto: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... <mailto: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... > <mailto: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... <mailto: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... <mailto: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... > <mailto: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... > <mailto: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... > <mailto: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... > <mailto: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... > <mailto: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... > <mailto: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... > <mailto:xml...@li...> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > > > -- > Kis Gergely > MattaKis Consulting > Email: ger...@ma... <mailto:ger...@ma...> > Web: http://www.mattakis.com > Phone: +36 70 408 1723 > Fax: +36 27 998 622 > > > > ------------------------------------------------------------------------------ > 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 |
