Hi Thomas, Thomas Neidhart wrote:
> Hi, > > I have installed the following JDK on my machine: > > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxi3260sr12-20121025_01(SR12)) > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 > jvmxi3260sr12-20121024_126067 (JIT enabled, AOT enabled) > J9VM - 20121024_126067 > JIT - r9_20120914_26057 > GC - 20120928_AA) > JCL - 20121014_01 > > When I try to run the following test from the IBM developerworks wrt > WeakReferences and ReferenceQueue, the reference is never put on the > reference queue (the problem that I also had in the WeakHashtable > testcase): > > url: http://www.ibm.com/developerworks/library/j-refs/ > > output: > > Example of incorrectly holding a strong reference > object is MyObject@3b203b2 > The weak reference is java.lang.ref.WeakReference@46d046d > Polling the reference queue returns null > Getting the referent from the weak reference returns MyObject@3b203b2 > Calling GC > Polling the reference queue returns null > Getting the referent from the weak reference returns null > > Example of correctly releasing a strong reference > object is MyObject@2bd62bd6 > The weak reference is java.lang.ref.WeakReference@37c637c6 > Polling the reference queue returns null > Getting the referent from the weak reference returns MyObject@2bd62bd6 > Set the obj reference to null and call GC > Polling the reference queue returns null > Getting the referent from the weak reference returns null > In finalize method for this object: MyObject@3b203b2 > In finalize method for this object: MyObject@2bd62bd6 > > > Polling the reference queue always returns null, even when the > WeakReference has lost its referent. > > Can somebody confirm this? IMHO the test is incorrect. I remember another article about the GC and it was stated, that the GC cannot garbage collect objects with a finalizer method immediately. It will keep such objects in a special area and return them to the queue at its next run when the finalizer has been finished (and therefore it is counter-productive to implement that method). That article might have been explained GC strategies of newer JDKs (6/7) while this IBM article is ancient. With the original test I face a 50% chance that the finalizer method runs after polling the queue. IMHO you should modify the test to call the GC twice in a row to get proper results for modern GCs. At least then I have the expected effect for my IBM 4/5/6 JDKs (amd64-64). Funny enough it does not work for my Oracle JDK 7, actually you cannot rely at all to System.gc() calls, because you have no idea about the JDKs GC strategy. ;-) - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
