Circular References in Java

Question

I want to build my android project with proguard.while exporting it gives such error log.Please give me a solution.

 Warning: there were 28 unresolved references to classes or interfaces.
          You may need to specify additional library jars (using '-libraryjars').
java.io.IOException: Please correct the above warnings first.
    at proguard.Initializer.execute(Initializer.java:321)
    at proguard.ProGuard.initialize(ProGuard.java:211)
    at proguard.ProGuard.execute(ProGuard.java:86)
    at proguard.ProGuard.main(ProGuard.java:492)

Solution 1

Only a very naive implementation would have a problem with circular references. Wikipedia has a good article on the different GC algorithms. If you really want to learn more, try (Amazon) Garbage Collection: Algorithms for Automatic Dynamic Memory Management . Java has had a good garbage collector since 1.2 and an exceptionally good one in 1.5 and Java 6.

The hard part for improving GC is reducing pauses and overhead, not basic things like circular reference.

Solution 2

The garbage collector knows where the root objects are: statics, locals on the stack, etc and if the objects aren't reachable from a root then they will be reclaimed. If they are reachable, then they need to stick around.

Solution 3

Ryan, judging by your comment to Circular References in Java, you fell into the trap of referencing objects from a class, which was probably loaded by the bootstrap/system classloader. Every class is referenced by the classloader that loaded the class, and can thus be garbage-collected only if the classloader is no longer reachable. The catch is that the bootstrap/system classloader is never garbage collected, therefore, objects reachable from classes loaded by the system classloader cannot be garbage-collected either.

The reasoning for this behavior is explained in JLS. For example, Third Edition 12.7 http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7.

Solution 4

If I remember correctly, then according to the specifications, there are only guarantees about what the JVM can't collect (anything reachable), not what it will collect.

Unless you are working with real-time JVMs, most modern garbage collectors should be able to handle complex reference structures and identify "subgraphs" that can be eliminated safely. The efficiency, latency, and likelihood of doing this improve over time as more research ideas make their way into standard (rather than research) VMs.

Solution 5

The Java specification says that the garbage collector can garbage collect your object ONLY If it is not reachable from any thread.

Reachable means there is a reference, or chain of references that leads from A to B, and can go via C,D,...Z for all it cares.

The JVM not collecting things has not been a problem for me since 2000, but your mileage may vary.

Tip: Java serialization caches objects to make object mesh transfer efficient. If you have many large, transient objects, and all your memory is getting hogged, reset your serializer to clear it's cache.

View more solutions

Comments

[Bill K]

If it couldn't be reached before, how did you know it went away? I wonder if there is some type of link you aren't thinking of that can cause the system to keep it. A thread or a listener.

[Brian]

How did you know whether the objects were being garbage collected or not when you must have dropped all references to them? Were they weak references or did you have a link to them through JNI or was it some kind of live object that can be collected even as it is still active?

[Paul Tomblin]

The problem was that when we went to reference it, it was gone. I forget the exact details because it was a few months ago, but I think we were calling it through a RMI method.

[arviman]

Reference counting is a very good example of a naive implementation.

[ddimitrov]

And to emphasize the point, a JVM that assumes infinite heap and never garbage collects is fully compliant (although inefficient ;-)

[Will Hartung]

Actually, it's kind of a clever implementation, it's also a rather simple implementation, and while it has its limitations, it's a viable algorithm, especially in memory constrained environments.

[Ryan Delucchi]

I've been reading up on MacOs development and apparently ObjectiveC supports both reference count based garbage collection as well as a more sophisticated scheme similar to that of Java.

[Ryan Delucchi]

It turns out that the memory leak can be traced to a class whose instances are stored in a collection, and the class itself has a reference (of type Object) to the the class objects in question - no, I didn't write the code for this one :-)

[Ryan Delucchi]

Actually, we thought that we had it figured out but unfortunately it is now looking like we don't have it. But yes, this is one possibility we should explore.