Archived

This topic is now archived and is closed to further replies.

does gc really gcs this

This topic is 5624 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

suppose i have a linked list, btw, this is a java related question, which has a structure something like this. [Head] ----> A <----> B <----> C <----> D <---- [Tail] where A <----> B means, the node A is pointing to node B and Node B is pointing back to node A. Ya, this is what u called double-headed ( double-directional ) linked list. Now the question is ; if i assign the "next" pointer of the [Head] and the "previous" pointer of the [Tail] to null in an attempt to clear the list, will the GC garbage collect all the nodes , A, B,C...... automatically or will they just remain in the memory and cause memory leak !. The scenario i''m describing is [Head]-->null null <--- A <----> B <----> C ----> null As far as i know, a memory gets garbage collected only when NOONE is pointing at it, isn''t it ? However, in this case, eventhough the nodes A,B C .... becomes unaccesible since both [Head] and [Tail] are pointing to null, they are still pointing to each other. So how will the Java''s GC know whether these nodes are really unaccesible or not from its machine''s point of view. Please help me out..... I''m really confused about it.

Share this post


Link to post
Share on other sites
I don''t know specifically about the java gc, but I know how the .NET GC works...java''s should be similar.

Objects are marked for collection when they go out of scope for all active threads. So A, B, and C would be collected if the only things referencing them are eachother.

The circular reference problem you''re worried about doesn''t exist in a GC environment, but does with reference counting (COM).

Epolevne

Share this post


Link to post
Share on other sites
Early Garbage Collectors used this "delete when no one is
pointing" technique, which fails miserably when there are
circulr references. The examples you provided show this.

Nowadays, GCs use "mark and sweep" and other techniques so
that "abandoned" circulr references are freed as well.

The Java GC is pretty smart, but there are still ways to
cause resource leaks if you really work it. But no, the
scenario you described should be fine.


~~~~
Kami no Itte ga ore ni zettai naru!

Share this post


Link to post
Share on other sites
It depends on the implementation of the JVM. There are very few requirements on the garbage collector specified by the java virtual machine specification... In fact, I''m not even sure that GC is required. It may be permissable to just throw an OutOfMemoryError when memory runs out without ever trying to reclaim any of the memory.

The type of garbage collection you''re thinking of is based on reference counting. Reference counting has several flaws, one of which is the inability to collect cyclic data structures. Another problem with reference counting is that it is much slower than other GC systems.

The garbage collector used by modern implementations of the JVM is a fairly sophisticated design. It uses a combination of generational and copy style garbage collectors. It determines which objects can be collected by doing a reachability analysis. For every thread in the JVM, the collector follows the object graph out, checking what objects can be reached from that thread. If an object cannot be reached from any thread, it is free to be garbage collected.

So, for your example, the solution is to not care about the connections between the nodes. Just make sure that your program doesn''t have any references to any of the nodes in the code that''s currently executing. Once you no longer are holding a reference to any of the nodes, the whole structure is elegible for garbage collection, and may be collected.

Note that typically the marked objects are only collected when the program is either stopped waiting for input or when it needs to collect the garbage to have enough memory to allocate a new one. If neither of those occur, unreachable objects may never be collected.

Share this post


Link to post
Share on other sites