Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of weldonwjw@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=V1FexCXh7yMXCXp0Y8rPsYzX+dZbZ2uudGTSuhMIs3ebu0UWNPxyF+01YNZT9yw/+smLbcMjfd7aliqQfyIxSOGD1uu28roVmFJUNitWTsGH0K1fVowh797LS/9DxHJC4xJplf0A+T0iererqebTMVWtexlRWhl19Q7CsgU2BDk=
Message-ID: <4dd1f3f00701012051g70251f56p51bf76708af86b70@mail.gmail.com>
Date: Mon, 1 Jan 2007 20:51:39 -0800
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] finalizer design questions
In-Reply-To: <4599DA06.1090803@anu.edu.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_173251_21298634.1167713499632"
References: <4dd1f3f00612211832u447fa2e4i90b4eb108762af8f@mail.gmail.com>
	 <4AFE8DB0-26D1-4CA1-A7D9-FCAD13AC33A4@pobox.com>
	 <9623c9a50612261730k1c7342c3m9ad6b3d158cedcd1@mail.gmail.com>
	 <866ECD92-8D0F-4F0D-B214-1B27A8870C5A@pobox.com>
	 <4dd1f3f00612271834j7afa7a06v5778d3783df525db@mail.gmail.com>
	 <783bf8b0612280743k26dd70d9qe290fe635b70593b@mail.gmail.com>
	 <783bf8b0612290350r6f175763ucf36f49b6db10879@mail.gmail.com>
	 <4dd1f3f00612310718t23fd2cf6tb178d9cb0e97b9dd@mail.gmail.com>
	 <783bf8b0701010524r6b00b4aamc0fbefccbdde06ef@mail.gmail.com>
	 <4599DA06.1090803@anu.edu.au>

------=_Part_173251_21298634.1167713499632
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/1/07, Robin Garner <robin.garner@anu.edu.au> wrote:

> Pavel Afremov wrote:
> > On 12/31/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> >>
> >> This looks good to me.  Its close enough for the current state of
> >> drlvm.  In
> >> other words, don't try to precisely replicate the performance numbers I
> >> collected from Sun 1.5.0.
> >
> >
> >
> > 1/50 ratio with usual work load for finalization system is not good,
> > because
> > it means 2% VM performance for main task. Let's evaluate following
> > abstraction. For example for finalization of some objects requires the
> same
> > time as for creation. These objects were generated during 10 seconds for
> > example. So machine will works with 2% performance for main task during
> 10
> > seconds when finalizer is works. Finalization shouldn't stop main task,
> and
> > 2% of performance equals stopping.
>
> I think this is missing the point.  Finalizers that run for a long time
> shouldn't be created.


Well put.  Thank you.


> - Finalizers should be run with high priority because memory (possibly
> large structures) can't be freed until they have completed.


I agree.


> - Allowing the main application to make some progress while a badly
> written finalizer executes is good design practice


Exactly right.


> I think this is the only criteria by which a finalization scheme can be
> evaluated.  Whether the ratio is 1/50, 1/25, 1/200 is neither here nor
> there.


Absolutely correct.


> From what I've seen to date, all the available DRLVM mechanisms are
> perfectly adequate,


 Yes with one reservation.  I'd like to see the existing DRLVM
mechanisms hard coded for just one finalizer thread for now.  And that no
finalizer code  be committed that suspends/resumes java app threads.  The
intention is to reduce debug confusion.  We have plenty of problems in the
threading subsystem that need sorting out.  Adding finalizer threads that
come and go along with starting/stopping java threads based on finalization
load factor is way too confusing.


> and we should all get back to doing something
> productive.


Good point.   As painful as it is, hammering out a workable design is
actually productive.  Robin, thanks for bearing with us through this
process.  As usual, your input is valuable.


> best regards,
> Robin
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
> http://cs.anu.edu.au/people/Robin.Garner/
>

-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

------=_Part_173251_21298634.1167713499632--