Question

In the following code we rotate a complex number by some angle in a loop and then confirm that the resulting number is identical to the one we started with.

public class Complex {
    private float r, i;
    ...
    public Complex(Complex other) {
        r = other.r;
        i = other.i;
    }

}

Complex z1 = new Complex(..);
Complex z1_save = new Complex(z1);
Complex z2 = new Complex();
Complex k = new Complex();
k.set_to_first_root_of_unity(8);
int n = 64;
while(n-- != 0) {
    z1.multiply(k, z2);
    z1 = new Complex(z2); // Line Y
}
Assert.assertEquals(true, z1.equals(z1_save));

Is there a way in Java to write Line Y using the constructor public Complex(Complex other) rather than clone(), and be certain that 64 objects will not be garbage collected?

Update: It seems it is impossible to ask this question in a simplified manner without referring to the context—that of an interactive application. The best answer to the present question so far (assylias’s) is that one should not worry about object creation and garbage collection 90% of the time. During redraw, it is necessary to worry about it 100% of the time. I have now restated the question here.

Answer 1

I am worried about the inefficiency of the GC running 64 times unnecessarily.

That is an unnecessary worry. If your objects are in the young generation (which they will considering their scope) GC will be free (as in 0 cost).

When the GC runs on the young generation, it only goes through live objects (objects that are eligible for GC are not visited), so the GC time is a function of the live objects only.

The story is different for the old generation, but your local objects won’t reach that stage.

Reference – Brian Goetz, emphasis mine:

What about deallocation?

But allocation is only half of memory management — deallocation is the other half. It turns out that for most objects, the direct garbage collection cost is — zero. This is because a copying collector does not need to visit or copy dead objects, only live ones. So objects that become garbage shortly after allocation contribute no workload to the collection cycle.

?It turns out that the vast majority of objects in typical object-oriented programs (between 92 and 98 percent according to various studies) "die young," which means they become garbage shortly after they are allocated, often before the next garbage collection. (This property is called the generational hypothesis and has been empirically tested and found to be true for many object-oriented languages.) Therefore, not only is allocation fast, but for most objects, deallocation is free.