How can object and subinstances become eligible for garbage collection?

[Carlos Conti]

Hi,

I have an application where in a simplified manner I have several object which interact with eachother in the fashion:

class A{

B b = new B(a);
C c = new C(a);


}

class B {... redundant...} //bear in mind it is holding an A reference

class C {... redundant...} //bear in mind it is holding an A reference

All classes are mapped to an Hibernate persistence layer.
When I finish an edition UserCase on an instance of class A, I want all of it to become eligible for garbage collection. What I do is to cancel all references from the UserCase code to the A instance to become null, for the A object to become eligible for Garbage Collection. The point is that since the B and C objects hold references to the A object, A isn't Garbage Collected, I presume because the A object is still referenced by B and C. But under this assumption, what I need to do is to manually deconstruct the A object so that B and C have its A reference set to null, for the A object to be finally collected. Similarly I would have to do the same thing for B and C, should their instances be hold somewhere.

This is a big simplification. My model consists of over 150 classes and that means I have to build a standardized method of attaining this if I want to avoid programming a deconstruction method for each class in the model.

Since every class is hibernate annotated, I can figure out a (not so easy to do) task to accomplish that.

However if anybody knows a quicker way, I would really love to know about it, then it would save quite a lot of research time.

Do I have to push for that solution? Or does anyone know a more straightforward method?

Many thanks in advance for your insights.

Regards,

Carlos.

[Paul Clapham]

Carlos Conti wrote:When I finish an edition UserCase on an instance of class A, I want all of it to become eligible for garbage collection.

Why? It seems to me you're looking for problems where they don't exist -- or is there a problem which occurs if those objects aren't garbage-collected?

[Carlos Conti]

Hi Paul, many thanks.

Where is the no problem if you leave those references there... in the end they turn out to be tiny memory leaks.... which will add up heap usage and increase the chances of OutOfMemory errors upon throughput or traffic increase... or is there a point in time where they will be GC'd?. If so under which criteria?

My strategy consists on cleaning up after use. This way I can guarantee OoM errors will only appear due to heavy usage.... where I can estimate average user heap needs and making the ammendments in the server accordingly for a foreseen concurrent user base.

What do you think? I am not an expert on this subject but this appears to be correct. Would you suggest differently?

Thanks,
Carlos.

[Dave Tolls]

Carlos Conti wrote:The point is that since the B and C objects hold references to the A object, A isn't Garbage Collected, I presume because the A object is still referenced by B and C.

The circular referencing here is irrelevant if there is no valid connection from the root to the A object in question.
That means a reference to A, B or C exists outside of the A object you want GCed.

[Paul Clapham]

The normal Java strategy is this: Try not to keep references to objects which you don't need. You seem to be trying to follow that strategy, but in a way which looks strange to me.

Let me put it this way: you have a B object which contains references to a set of A objects. But you say at some point you don't need those A objects any more, so you're going to change your B object so it doesn't refer to them any more and so they can be garbage collected. That's all very well if the design of B says that it just needs the A objects at the beginning and doesn't need them later. But if that isn't part of the design, then your drive to save memory by dereferencing the A objects might be damaging the B objects.

And if your B objects are actually designed so that they hang on to A references after the point where they need them, then there must be a point in the processing where the design says they are not needed any more, and something could kick in which dereferences them. But I can't see that being the case for all 150 classes in your application.

[Carlos Conti]

Hi all,

thanks for the short discussion. After some trial error and research we finally found the root of our problems and effectively cleaned up resources in a standard manner. As Dave Tolls pointed, the circular reference was not the issue, but some static instances which where holding A objects without a foreseen unload() schema.

But holoding instances from A, B or C, as long as there is no other participant and references exist only among those references is fine. They are all GC'ed once you detach them from the GUI classes as a whole.

We were attaining the job manually where there was already an automated task.

Many thanks,

Carlos Conti.

[Tapas Chand]

Carlos Conti wrote:...They are all GC'ed once you detach them from the GUI classes...

This statement should be...
They are all eligible for Garbage Collection once you detach them from the GUI classes.

When GC will occur, it is upto the JVM/Garbage Collector. It cannot be controlled by the programmer.