Retain cycles in jdk based classes

[parveen-bhatia]

I found retain cycles in JDK based java classes which cause memory leaks on iOS. Below are some snapshots from Instrument Leaks tool.

• LinkedHashMap retain cycle:

• DateTimeFormatterBuilder retain cycle:

Similarly, there seems retain cycle in AbstractMap. Because AbstractMap retains values and values() use anonymous inner class which has implicit reference back to AbstractMap.

Does j2objc takes care of memory leaks in JDK by patching them or any other way ?

[tomball]

The j2objc version of the JDK has extensive work done on these classes to avoid leaks by replacing inner classes with static inner classes, plus annotations for Weak and WeakOuter situations. In LinkedHashMap.java, the LinkedKeySet inner class has a WeakOuter annotation, so if you build j2objc and then view jre_emul/build_result/Classes/java/util/LinkedKeySet.m, you'll see:

@interface JavaUtilLinkedHashMap_LinkedKeySet () {
 @public
  WEAK_ JavaUtilLinkedHashMap *this$0_;
}

It looks like the problem might be with the WEAK_ definition in jre_emul/Classes/J2Obj_common.h:

#if __has_feature(objc_arc_weak)
# define WEAK_ __weak
#else
# define WEAK_ __unsafe_unretained
#endif

Google's internal build (which its testing is based on) builds jre_emul with clang's -fobjc-weak flag, but the public build's jre_emul/environment.mk doesn't include it in its OBJCFLAGS definition. Without that flag, what should be weak references are instead just unmanaged pointers.

So try adding -fobjc-weak to that definition, rebuild and retest for leaks. Please report back if that works, so the j2objc maintainers can fix the public build.

[parveen-bhatia]

I added -fobjc-weak flag as below:

Then recompiled j2objc using make dist clean. And used that generated j2objc to transpile.

But Instrument Leaks tool still showing retain cycles with jre classes.
Do we need to do something else in this case ?

[tomball]

Maybe the -fobjc-runtime-has-weak flag doesn't set the objc_arc_weak runtime feature, checked in J2ObjC_common.h. However, that test shouldn't be necessary anymore, since Objective-C weak references should always be used. I submitted a pull request that changes the objc_arc_weak test to fail compilation if false.

#if __has_feature(objc_arc_weak)
# define WEAK_ __weak
#else
# error j2objc requires zeroing Objective-C weak references.
#endif

This should build without errors and force all WEAK_ macros to be __weak. If this error directive is tripped in any client files, then fix the failing file to build with zeroing weak references (add -fobjc-arc or -fobjc-weak).