[If you're not interested in VM theory, it's safe to ignore this post] 2009/10/10 Christopher Schultz <ch...@christopherschultz.net>: > What about classes with mutable static members? These members should be > preserved for a while, right? Does this mean that classic Java > singletons are never able to be GC'd because they have a private static > member that points to an instance of the Class that cannot be cleared?
Most modern garbage collectors have at their heart a technique called mark-sweep garbage collection, which allows them to get round this problem. Conceptually, the collector runs in three phases and requires a bit in the object header (the "mark bit"). Most practical GCs have several optimisations over the basic technique, but the idea's the same. Phase 1: The collector clears the "mark bit" in all objects. Phase 2: The collector starts from the set of root objects that are known to be "live" (the current stack frame, for example - the precise set of roots depends on the language, and I know this lot from Smalltalk not Java) and chases references from these objects. Every time it reaches an object that does not have its mark bit set, the collector sets that object's mark bit, then traces all the references from that new object. Repeat until there are no more references to trace. By now, all objects that are reachable from the root have their mark bit set; all others have their mark bit cleared. Phase 3: Remove the dead objects by copying live objects towards one end of the heap, fixing up pointers as you go. Voila, one heap full of live objects, with all dead reference loops removed as none of the objects in the loop ever got marked. I learned about this lot the hard way when I was trying to alter the Squeak Smalltalk GC to deal with an alternative object header that I wanted to add. I'll just mention that debugging GCs is *hard* - Dan Ingalls, who has written several Smalltalk VMs, referred to it as "like studying frogs using a blender". After the n'th time my garbage collector created a fine goo of incorrectly-compacted objects and misaligned object pointers out of the original objects, I was inclined to agree. - Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
