From: <mi...@gm...> - 2008-11-25 17:45:49
|
Ok I guess code is worth a thousand words. The code below prints "I am finalized" before it prints "********done********" when the jvm is pressed for memory (thus the 1000000). Although I hold onto Softreferences and Weakreferences objects still do get finalized. Can you guys tell me how I would enable finalization in refcounting GC. Thank you package edu.gc; import java.lang.ref.SoftReference; import java.lang.ref.WeakReference; import java.util.ArrayList; public class GCTest { /** * @param args */ public static void main(String[] args) { ArrayList<SoftReference> softRefs = new ArrayList<SoftReference>(); ArrayList<WeakReference> weakRefs = new ArrayList<WeakReference>(); for (int i = 0; i < 1000000; i++) { Object o = new Object(){ @Override protected void finalize() throws Throwable { // TODO Auto-generated method stub super.finalize(); System.out.println("I am finalized"); } }; softRefs.add(new SoftReference(o)); weakRefs.add(new WeakReference(o)); } System.out.println("*******************************done*******************************************"); } } On Mon, Nov 24, 2008 at 6:29 PM, Daniel Frampton <zyr...@zy...>wrote: > A quote from the API documentation for reference types [1] > > "Going from strongest to weakest, the different levels of reachability > reflect the life cycle of an object. They are operationally defined as > follows: > > - An object is *strongly reachable* if it can be reached by some thread > without traversing any reference objects. A newly-created object is strongly > reachable by the thread that created it. > - An object is *softly reachable* if it is not strongly reachable but > can be reached by traversing a soft reference. > - An object is *weakly reachable* if it is neither strongly nor softly > reachable but can be reached by traversing a weak reference. When the weak > references to a weakly-reachable object are cleared, the object becomes > eligible for finalization. > - An object is *phantom reachable* if it is neither strongly, softly, > nor weakly reachable, it has been finalized, and some phantom reference > refers to it. > - Finally, an object is *unreachable*, and therefore eligible for > reclamation, when it is not reachable in any of the above ways." > > Finalization sits between weak references and phantom references. > > First thing to note is that these are defined by *reachability*, a > transitive property which of course reference counting has difficulties with > (this is where the atomicity/consistency properly Eliot mentioned creeps > in). > > To have something that works with reference counting you need to resort to > some sort of tracing collection to estabilish the necessary properties, or > you have to break the semantics. > > For example, if an object needs to be finalized you must first establish > that it has no references to it, and then ensure it is not collected (and of > course all its referents recursively are also not collected). > > Imagine a singly linked list of length N with all finalizable objects. The > three simple implementation choices I know of involve 1) Having just one > element at a time get finalized.. which means you need something like 2*N > deferred RC collections to collect the whole list, and you are still not > meeting the specification (the whole group should be finalized together). 2) > Reverting to an algorithm roughly similar to trial-deletion to do partial > tracing for candidates of each type at each collection. This would be > difficult to get correct and expensive both in terms of the direct cost of > performing it, and the indirect costs it may impose on the rest of the > reference counting collector. 3) Combining the work of finalization and > reference processing with a tracing cycle detector. If the collector is > concurrent or incremental there will be some issues with correctness. Also, > processing of reference types and finalizable objects would be not as > timely, and so programs with many such objects may suffer (essentially > falling back to a tracing collection policy). > > Supporting just weak and phantom references is probably workable, > but---given the inability to easily support the full set---for now they are > all disabled. > > Cheers, > Daniel. > > [1] > http://java.sun.com/javase/6/docs/api/java/lang/ref/package-summary.html > > On Tue, Nov 25, 2008 at 4:46 AM, <mi...@gm...> wrote: > >> On Mon, Nov 24, 2008 at 12:27 PM, Eliot Moss <mo...@cs...> wrote: >> >>> Sure ... First, I suggest you read up on the descriptions of the >>> java.lang.ref classes. >> >> I have used these and I think I understand them a little :) >> >>> When these object become unreachable, >>> they can cause their referent to become reachable (certainly >>> to some threads) and possibly more generally "resurrected". >>> Further, in WeakReference, objects need to be recognized as >>> only weakly reachable *in groups*, i.e., there is a kind of >>> atomicity requirement. >> >> From my understanding of these, Weak references should have no impact on >> the referred objects finalization or(Ref count). In other words the GC could >> ignore these kind of references and every thing would work correctly. So >> that's why I fail to understand why these would be a problem. On top of that >> seems like to me a predictable GC (i.having guranteed predictable >> finalization) would have no need for week refrences. >> >> Thanks Babar >> >>> >>> >>> Best wishes -- Eliot >>> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |