0

Suppose I have a circular reference like so:

class A {
    B b = new B(this);
}

class B {
    A a;

    B(A a) {
        this.a = a;
    }
}

When an instance of A and the instance of B it references become unreachable, I understand that they will eventually become garbage collected. However, would they be garbage collected sooner if B didn't reference A back?

My concern is based on this note in the Python docs:

cycles are automatically reclaimed when garbage collection is enabled and they become unreachable, but it remains more efficient to avoid creating cycles.

My limited understanding is that this is because CPython also uses reference counting which can reclaim objects sooner when there are no cycles, but I'm not sure. I see that at least some implementations of Java don't use reference counting so this wouldn't apply. But really I don't know what I'm talking about and would like some confirmation.

Alex Hall
  • 34,833
  • 5
  • 57
  • 89
  • 1
    @sebadagostino I have now emphasised "I understand that they will eventually become garbage collected". My question is about performance, not correctness. If the duplicate answers my question, I don't see it (I don't want to read every answer and comment and link). – Alex Hall Jun 09 '18 at 21:07
  • there is no impact on performance. both these objects are no more reachable. It does not matter that they reach each other. – gagan singh Jun 09 '18 at 21:25
  • @AndyTurner I don't if it's possible to notify you, can you respond to my claim that it's not a duplicate? – Alex Hall Jun 09 '18 at 21:29
  • 1
    The Java garbage collector starts from the active roots and marks "live" objects by traversing references from these roots. Reference cycles in unreachable objects are never traversed and therefore have no performance impact. – Thomas Kläger Jun 09 '18 at 21:34
  • @ThomasKläger this is pretty much what I figured, I guess my question more specifically is does the JVM use any secondary method to handle completely isolated objects more efficiently, the way Python uses reference counting? If not, is there a source that could confirm this? – Alex Hall Jun 09 '18 at 21:59
  • 2
    Short answer: 1) No, it doesn't. 2) The source code is available for you to confirm this for yourself. Java objects don't have reference counts. – Stephen C Jun 10 '18 at 02:00
  • And you can also confirm this by writing a Java class that *would* require reference counts, compile it, run it with the JVM flags that cause native code to be displayed by the the JIT compiler ... and look for any native code that increments / decrements the hypothetical ref counts. – Stephen C Jun 10 '18 at 02:10
  • The JVM completely ignores completely isolated objects. That's the primary approach. And, since they are completely ignored, no secondary approach is necessary - it doesn't matter what these objects contain. – Thomas Kläger Jun 10 '18 at 07:58
  • @AlexHall “…more efficiently, the way Python uses reference counting” is a contradiction in itself. Reference counting is not efficient. The need for updates on a counter for every assignment is rather inefficient. Reference counting is simpler to implement, may cope better with smaller heap sizes, but is not more efficient. The JVM doesn’t even need to touch dead objects, regardless of how many there are. What could be more efficient than that? – Holger Jun 12 '18 at 13:20
  • @Holger AFAIK Python uses both reference counting and Java-like garbage collection. Maybe I'm completely wrong. If it does, surely there's a reason for that? Isn't reclaiming unused memory sooner a good thing? – Alex Hall Jun 12 '18 at 13:29
  • I know, this may contradict what you can read in old books or what your system administrator will tell you, but “reclaiming unused memory sooner” is not useful in itself. Reclaiming memory is useful when there is an actual need for that memory. Otherwise, reclaiming it just means make a meaningless number bigger. And within the JVM, the memory manager knows when memory is needed, hence, can reclaim memory right on time instead of wasting CPU cycles to do it earlier. From the outside, the heap usually looks like a big pre-allocated chunk of memory anyway, without a notion of “used” or “unused”… – Holger Jun 12 '18 at 13:40
  • @Holger cool, that helps. Thanks! – Alex Hall Jun 12 '18 at 14:12

0 Answers0