On Mon, Aug 23, 2010 at 8:55 PM, Giampaolo Tomassoni <giampa...@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
