You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Giampaolo Tomassoni <Gi...@Tomassoni.biz> on 2010/08/23 12:41:13 UTC
GC wonders
I have a question to spare, which arouses me by ages: how does the JVM
elegits circularly-referenced objects for garbage collection?
Let me explain it better. Having 2 classes:
public class A {
B b;
}
public class B {
A a;
}
and instantiating them in such a way to have the A instance refer to the B
one via its b field, and the B instance refer the A one via its a field,
when there isn't anymore other references to the instance of A and the
instance of B apart their own circular references, how can the JVM GC
understand that they may be both garbage-collected.
Or instead they are simply not recollected and the various WeakReference
versions are there exactly to avoid non-recollectable circular references?
Regards,
Giampaolo
Re: GC wonders
Posted by Deven You <de...@gmail.com>.
2010/8/23 Giampaolo Tomassoni <Gi...@tomassoni.biz>
> > Hope this will help you.
>
> It will, thank you. Now I can sleep better... ;)
>
> I now understand why the GC is regarded as being "the beast" in JVM: this
> reference graph traversal seems really time consuming, isn't? I always
>
As far as I know, there are some new techniques like parallel/concurrent GC
which may solve this problem.
imagined this process like somehow more "local". It instead is basically
> walking every and each object reference to discover unreferenced objects,
> right?
>
> I suppose this also means some per-instance helping fields must be handled
> in the internal representation of object instances. In example, I suppose
> objects are in a list, with possibly next and previous instance pointers in
> each list item, and possibly two further next and previous pointers to
> construct a "list of deleteables", from which instances are removed every
> time a reference points to them during tree traversal.
>
> Regards,
>
> Giampaolo
>
>
Re: GC wonders
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Mon, Aug 23, 2010 at 8:55 PM, Giampaolo Tomassoni
<Gi...@tomassoni.biz> wrote:
>> Hope this will help you.
>
> It will, thank you. Now I can sleep better... ;)
>
> I now understand why the GC is regarded as being "the beast" in JVM: this
> reference graph traversal seems really time consuming, isn't?
Probably. GC as a desirable feature deserves some cost. (Well actually
the traversal process
itself may not be the most time consuming part of a collection
procedure. It depends on the
GC algorithm. For example if GC wants to compact the live objects to
one end of the heap, then
the compaction time might be even longer.)
> I always
> imagined this process like somehow more "local". It instead is basically
> walking every and each object reference to discover unreferenced objects,
> right?
Right, it has to go through everybody to check their referenced
objects. (Well, it actually also
depends on the GC algorithm and other supporting stuff. One collection
can collect only part
of the heap, by remembering those references pointing from outside
this heap part to it. Then
it does not need to traverse the outside heap, for this time collection.)
> I suppose this also means some per-instance helping fields must be handled
> in the internal representation of object instances. In example, I suppose
> objects are in a list, with possibly next and previous instance pointers in
> each list item, and possibly two further next and previous pointers to
> construct a "list of deleteables", from which instances are removed every
> time a reference points to them during tree traversal.
There are many ways to remember/recycle those unreachable objects. For
example, if you want,
you can traverse the heap and mark those live objects, and then
traverse the heap again to recycle
those unmarked objects.
Thanks,
xiaofeng
> Regards,
>
> Giampaolo
>
>
--
http://people.apache.org/~xli
RE: GC wonders
Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> Hope this will help you.
It will, thank you. Now I can sleep better... ;)
I now understand why the GC is regarded as being "the beast" in JVM: this
reference graph traversal seems really time consuming, isn't? I always
imagined this process like somehow more "local". It instead is basically
walking every and each object reference to discover unreferenced objects,
right?
I suppose this also means some per-instance helping fields must be handled
in the internal representation of object instances. In example, I suppose
objects are in a list, with possibly next and previous instance pointers in
each list item, and possibly two further next and previous pointers to
construct a "list of deleteables", from which instances are removed every
time a reference points to them during tree traversal.
Regards,
Giampaolo
Re: GC wonders
Posted by Deven You <de...@gmail.com>.
I think there is a concept of root set of references which means global
references like class static fields and references in current stack. If an
object is not referenced by any references in root set, GC think it is
unused and can be collected.
In your case, suppose there is another class C:
public class C {
public static A aInstance;
}
aInstance is a global reference and thus in root set
If an application sets aInstance to point your A instance, when GC traverses
the object reference graph, it finds A instance referenced by aInstance, and
B instance is referenced by A instance (so it is also indirectly referenced
by aInstance); then GC knows A instance and B instance both have at least
one reference from root set (aInstance). GC won't colloct A instance and B
instance. If now the application sets aInstance as null, the next time GC
runs, it will find there is no any reference in root set which points to A,
GC will know A instance and B instance are no longer referenced by any
reference in root set. thus GC will recollected them. Hope this will help
you.
2010/8/23 Giampaolo Tomassoni <Gi...@tomassoni.biz>
> I have a question to spare, which arouses me by ages: how does the JVM
> elegits circularly-referenced objects for garbage collection?
>
> Let me explain it better. Having 2 classes:
>
> public class A {
> B b;
> }
>
> public class B {
> A a;
> }
>
>
> and instantiating them in such a way to have the A instance refer to the B
> one via its b field, and the B instance refer the A one via its a field,
> when there isn't anymore other references to the instance of A and the
> instance of B apart their own circular references, how can the JVM GC
> understand that they may be both garbage-collected.
>
> Or instead they are simply not recollected and the various WeakReference
> versions are there exactly to avoid non-recollectable circular references?
>
> Regards,
>
> Giampaolo
>
>
>