Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 20850 invoked from network); 13 Apr 2007 15:52:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Apr 2007 15:52:54 -0000 Received: (qmail 36312 invoked by uid 500); 13 Apr 2007 15:52:57 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 36277 invoked by uid 500); 13 Apr 2007 15:52:56 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 36268 invoked by uid 99); 13 Apr 2007 15:52:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Apr 2007 08:52:56 -0700 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=MAILTO_TO_SPAM_ADDR,RCVD_IN_SORBS_WEB,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of oliver.deakin@googlemail.com designates 66.249.92.169 as permitted sender) Received: from [66.249.92.169] (HELO ug-out-1314.google.com) (66.249.92.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Apr 2007 08:52:49 -0700 Received: by ug-out-1314.google.com with SMTP id z36so444531uge for ; Fri, 13 Apr 2007 08:52:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ktSFCWYYa50Tmp1y4N9GJRxBEm1E+FW9EPpGw0BWRo1vN8pCwYZvwe8MFFMuv/MgtiSz88J5bJ6VC6drlJT/H/0urL6VANq3vlpBDLL5EBB4+dA0TiFx6A082pAkjACdc2kZj7aFZyPCBTSTg8gMAKdO9MQfQKpgWqCFiMMwKMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ivR0JMKsRUmYlRbxgva7d/pzHhgXhkEU5N/7lgtRuTBoq7fW1QHdUsiMiw2c++SRNvnyO/bXrBFIQevL6cAAuCxVNtqy5xG8wkygSBJT96GGf9rDDX8i4Lg6bCaGldEUzZDwOQ4sBgEUlX/vuScnurYU9BzWkZ0AExJM0p8wLHg= Received: by 10.67.98.9 with SMTP id a9mr2086640ugm.1176479548329; Fri, 13 Apr 2007 08:52:28 -0700 (PDT) Received: from ?9.20.183.80? ( [195.212.29.92]) by mx.google.com with ESMTP id e1sm5435470ugf.2007.04.13.08.52.27; Fri, 13 Apr 2007 08:52:27 -0700 (PDT) Message-ID: <461FA773.10502@googlemail.com> Date: Fri, 13 Apr 2007 16:53:23 +0100 From: Oliver Deakin User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [classlib][testcase] should weakreference be queued in runFinalization()? References: <9623c9a50704121937w56c8f045t35fba03ac80f2d59@mail.gmail.com> <461F4428.8000109@googlemail.com> <9623c9a50704130204x207134ffrf81f56eac5f24eee@mail.gmail.com> <9623c9a50704130641m15575605n9096135ec7ec70ae@mail.gmail.com> In-Reply-To: <9623c9a50704130641m15575605n9096135ec7ec70ae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org The other way I can think of to force a gc, and thus hopefully have the weak reference cleared, is to do the following: - restrict heap size to a very small amount when launching the VM. - create WeakReference object and its referent. - fill heap with dummy objects until OutOfMemory is achieved (at which point you should be able to assume that at least one gc has occured, as it is unlikely that the memory manager will not have gc'ed at all before giving OOM). - free up dummy objects and check WeakReference. IMO it's a pretty ugly way to test this, but perhaps it's the only way to make sure that a gc really does occur. Regards, Oliver Xiao-Feng Li wrote: > On 4/13/07, Leo Li wrote: >> I think it assured that the reference is eventually enqueued. So is it >> possible to test it before VM shutdown by means of JVMTI? (But I am >> not sure >> whether it is too late to get VM work properly.) > > It probably can't be tested just like you never know an object is > reclaimed. > > Thanks, > xiaofeng > >> On 4/13/07, Xiao-Feng Li wrote: >> > >> > On 4/13/07, Oliver Deakin wrote: >> > > The 5.0 spec for runFinalization() says: >> > > >> > > "Calling this method suggests that the Java Virtual Machine expend >> > > effort toward running the finalize methods of objects that have been >> > > found to be discarded but whose finalize methods have not yet >> been run." >> > > >> > > and for gc(): >> > > >> > > "Calling the gc method suggests that the Java Virtual Machine expend >> > > effort toward recycling unused objects" >> > > >> > > The key word in both those specs is /suggests/. There is *no* >> guarantee >> > > that any finalizers are run or that a gc actually occurs when these >> > > calls are made - it is only a hint to the VM. >> > > >> > > If a test is expecting these calls to definitely gc and run >> finalizers, >> > > then IMO the test is in error. >> > >> > Yes, I have the seem opinion. And both gc() and runFinalization() >> > actually say nothing about weakreference. Don't know why they are used >> > to test References. >> > >> > Thanks, >> > xiaofeng >> > >> > > Regards, >> > > Oliver >> > > >> > > >> > > Xiao-Feng Li wrote: >> > > > In classlib tests "gc.PhantomReferenceTest" and >> > > > "tests.api.java.lang.ref.ReferenceTest", they expect weakreference >> > > > objects be queued after System.runFinalization(). Is this >> correct? In >> > > > my understanding of the spec, there is no requirement on this >> > > > behavior. >> > > > >> > > > The tests do like this: >> > > > >> > > > ========================= >> > > > //wr is the weakreference, whose referent is only weakly >> reachable. >> > > > //rq is the reference queue >> > > > >> > > > System.gc(); >> > > > System.runFinalization(); >> > > > >> > > > ref = rq.poll(); >> > > > >> > > > assertTrue("Unexpected ref2", ref == wr); >> > > > assertNotNull("Object not garbage collected.", ref); >> > > > assertNull("Object could not be reclaimed.", ref.get()); >> > > > ========================= >> > > > >> > > > After runFinalization(), it requires the queue has the >> weakreference. >> > > > Actually it has requirement on System.gc() as well, requiring >> it to >> > > > identify the weakly reachable object accurately. >> > > > >> > > > In my understanding of the spec, this kind of tests are wrong. It >> > > > forces the GC to do something not required by spec. >> > > > >> > > > How do you think? >> > > > >> > > > Thanks, >> > > > xiaofeng >> > > > >> > > >> > > -- >> > > Oliver Deakin >> > > Unless stated otherwise above: >> > > IBM United Kingdom Limited - Registered in England and Wales with >> number >> > 741598. >> > > Registered office: PO Box 41, North Harbour, Portsmouth, >> Hampshire PO6 >> > 3AU >> > > >> > > >> > >> > > -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU