4

In this article: Xamarin - Use Weak References to Prevent Immortal Objects It says that if two objects strong reference each other, they will become imortal, meaning the GC cannot collect them, even if the objects are no longer in use by the application.

However, in these 2 SO discussions:

Garbage collector and circular reference

Circular References Cause Memory Leak?

It seems that circular reference can be handled by GC, as long as the objects are no longer in use by the application.

Do I misundersand anything? Does Java's GC behave differently on Android? I am really confused. Any comments are appriatiated. Thanks!

Community
  • 1
  • 1
Student222
  • 3,021
  • 2
  • 19
  • 24
  • 1
    Why did you link to two discussions on MS .Net if you want to know about the Android garbage collector? Which are you asking about? [.net](https://msdn.microsoft.com/en-us/library/ms404247%28v=vs.110%29.aspx) or [android](http://developer.android.com/reference/java/lang/ref/WeakReference.html)? For Android, [How to Leak a Context](http://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.html). – Elliott Frisch Apr 28 '16 at 16:20
  • 2
    That article seems plainly incorrect to me, the .NET GC is always implemented as a tracing GC that doesn't leak cycles as far as I'm aware. – Asik Apr 28 '16 at 16:33
  • 1
    @Asik same with Java. The article seems to assume GC based on reference count, which is not the case for Java or .NET. – CPerkins Apr 28 '16 at 16:59
  • @ElliottFrisch, The reason that I link two dot Net discussions is because that article is from Xamarin, a Microsoft subsidiary, which enables us to use dot Net on Android and IOS. – Student222 Apr 28 '16 at 17:44

3 Answers3

2

I'm not sure from your question what language or environment you care about, but in Java, there are no "immortal objects" of the kind you describe. The Java garbage collection is not based on reference count: it's based on reachability from the root. Since your two objects aren't referred to by anywhere else in the application, they're eligible for garbage collection.

CPerkins
  • 8,968
  • 3
  • 34
  • 47
2

Xamarin is based on Mono, which is essentially a (now) independent implementation of .NET. And like .NET, it bases garbage collection on reachability, not reference counting or presence. (The same thing is true for the Java GC system, but since Xamarin isn't based on Java, that's not really the point.)

Two objects that reference each other, but are otherwise unreachable in the program, are eligible for garbage collection. There is no need to use weak references to address that scenario, as the objects will be collected as soon as both objects cannot be reached by a "root" reference.

In other words, the article you're looking at is plainly incorrect. In fact, using weak references can lead to other issues, as keeping objects alive becomes more complicated, making it easier to write bugs into one's code. It is surprising to me that such erroneous information would appear on the Xamarin web site itself.

Peter Duniho
  • 68,759
  • 7
  • 102
  • 136
0

I did some researches and want to answer my own question. Below are some findings:

  • In both Java and C# world, circular reference is not a problem. GC can handle that very well. Therefore, for Xamarin Android, that article is irrelevant and misleading. However that article is listed under cross-platform...
  • In Obj-C or Swift world, they use reference counting. And circular references will indeed cause memory leak. So in Xamarin.IOS we need to be careful about that. UPDATE: Thanks to PeterDuniho's comment, to be accurate, for Xamarin.IOS, the managed world is governed by Mono, we need not worry about circles. But if two native objects strong reference each others, they will become immortal...

I think that's it. Link some references on this topic:

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Student222
  • 3,021
  • 2
  • 19
  • 24
  • _"So in Xamarin.IOS we need to be careful about that"_ -- if your managed code running under Xamarin directly used iOS memory allocators, you would. But it doesn't. Xamarin is a layer between your managed code and the OS; your code is using the Mono memory management system, and so purely managed objects behave the same as on other platforms. The only place the iOS memory system comes into play is when you use or extend native/peer objects, and the managed references don't affect that per se (but of course you always need to dispose disposable objects, just like in normal .NET code). – Peter Duniho Apr 30 '16 at 16:18