memory leak & question related to that

[Jon Gilbert]

Hi,

First of all, thanks Tom for all your help previously regarding Xalan, and for this great project. 

Everything seemed to be working swimmingly but coming up to release, I caught a memory leak while profiling memory use of our app. Using Instruments, I traced the leak to a couple of different complex retain cycles that appears to be occurring inside of the Apache Harmony XML code. Instruments shows 11 simple cycles (4 unique kinds) making up this first of the three kinds of complex cycles.  

The first simple cycle is:

OrgApacheHarmonyXmlDomElementImpl --- id <JavaUtilList> children_ ---> 

JavaUtilArrayList ---- IOSObjectArray* array_ -----> 

IOSObjectArray ---- id buffer [0] ----> 

OrgApacheHarmonyXmlDomTextImpl --- OrgApacheHarmonyXmlDomInnerNodeImpl* parent_ ---> BACK TO TOP (retain cycle)

Before I go into details on all the rest, I want to ask what the best approach to this would be. I read up on the memory management annotations that j2objc features, and the use of cycle finder. I tried running cycle finder between ElementImpl.java and TextImpl.java:

cycle_finder -classpath j2objc/dist/lib j2objc/jre_emul/android/libcore/luni/src/main/java/org/apache/harmony/xml//dom/ElementImpl.java j2objc/jre_emul/android/libcore/luni/src/main/java/org/apache/harmony/xml//dom/TextImpl.java 

However, I got hundreds of errors. I don't even know where to begin with that. 

I reviewed the "Memory Management" section of J2ObjC's online documentation, and reviewed the J2ObjC annotations related to memory management. So I added @Weak in the Apache Harmony java sourcecode front of the properties that Instruments reveals as being the offending references that are causing the retain cycles.  

This seemed to fix the problem.

I also found some similar leaks due to retain cycles inside of Xalan, and added @Weak to some properties in there as well. But there, I ran into the problem that import com.google.j2objc.annotations.Weak; fails inside of Xalan because Xalan cannot see that, since you put Xalan outside the main source code. 

How do I set things up where I can use @Weak inside of the Xalan source? I'm at a loss.

Thanks

Jon Gilbert

[j...@hellojory.com]

Yep, no matter what I do, I always get this error when making j2objc:

package com.google.j2objc.annotations does not exist
import com.google.j2objc.annotations.Weak;

... if I have tried to import the @Weak annotation into Xalan so I can fix its memory leaks. I tried everything, editing the make files to include the annotations classes, etc. Obviously I do not fully understand how these makefiles are set up, or else I would have fixed it already.

Please advise how to get annotations to work inside Xalan. Thanks.

[Keith Stanger]

For importing annotations in the xalan sources, try adding "-classpath $(DIST_JAR_DIR)/j2objc_annotations.jar" in the Makefile anywhere you also see a -sourcepath flag. (there appear to be three spots where this would go. You may also need to run "make annotations_dist" before building xalan to make sure the annotations jar is created.

Regarding XML cycles. The parent field on LeafNodeImpl.java (which TextImpl inherits) is marked as @Weak. So I would not expect the cycle you reported to cause a leak. Sometimes instruments can get false positives. If you can confirm that there is indeed a leak and can produce some test code to demonstrate it, then please file an issue and I'll be happy to look into it further.

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukhnos Liu]

I'd like to comment on the general approach. From my experience, starting with the Leaks instrument is the right thing to do. It catches a lot of low-hanging fruits, and the instrument has been getting better over time.

I use Cycle Finder both as supporting evidence and for verification -- I start with one of the classes that Leaks told me have leaks use Cycle Finder to show me the chain. I then match the report to that by Leaks. This helps me determine where to break the cycle, and I then use Cycle Finder and Leaks again to verify the fix.

Leaks does often report false positives. Not in the sense that they aren't over-retained, but in the sense that they are not the true cause -- they are simply retained by the leaked objects. One way to look past those is to focus on top-level objects. If a HashMap leaks, for example, I don't start looking into jre_emul's source immediately. Rather I'll trace upwards to see what's retaining the HashMap, and it's usually by some ComExampleSomeClassThatIsMyBusinessLogic, and that's where I investigate further.

There are also false negatives, and that's one reason Instruments pairs it with the Allocations tool -- Allocations is where the ground truth is. If you see the number of instances of some ComExampleSomeClassUsedOnlyInOnePlace grow over time (say by getting into and out of some view controller), it's a sign that there are tricky leaks that are beyond Leaks' ability to discover. Tackling those leaks will require more in-depth understanding of the code. Once I identify those and fix them, I'll put the name of the offending class in Allocation's search field, run the app, and watch as the number of the instances go up, then, after I get out of the view controller, the objects eventually disappear from the search result. :)

[Jon Gilbert]

OK I just submitted a pull request with my fixes. 

https://github.com/google/j2objc/pull/731#issuecomment-201071840

Seems to be working well for me on this end. No more memory leaks or tons of exceptions being thrown :D

- Jon