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 pavel.n.afremov@gmail.com
 designates 64.233.182.188 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=ngX14hc10vhUazzybccZFc5XgxO1NwFfEYuoiLSldxNfYLYNPgmR6fLEzvrLFC1f6C9L4Vef85TXPDB8lL7Nu2VvNwjFxaHnalPjNO+bOUu0KEaScwh8Ul1fkb/2enucg1c+L4eV0UwMESgJp17SWoN1VjC9iAiFVne+liRZKnU=
Message-ID: <783bf8b0612290114j3090a572m5343ef3e3469223@mail.gmail.com>
Date: Fri, 29 Dec 2006 12:14:00 +0300
From: "Pavel Afremov" <pavel.n.afremov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] finalizer design questions
In-Reply-To: <51d555c70612281054w605707e1qdae50150e8eeaee6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_104661_15778590.1167383640673"
References: <4dd1f3f00612211832u447fa2e4i90b4eb108762af8f@mail.gmail.com>
	 <866ECD92-8D0F-4F0D-B214-1B27A8870C5A@pobox.com>
	 <4dd1f3f00612271834j7afa7a06v5778d3783df525db@mail.gmail.com>
	 <9623c9a50612280633k18b934cbkc4c36b2611092485@mail.gmail.com>
	 <13D6EC44-4121-46B9-A710-003A3FAA5187@pobox.com>
	 <51d555c70612280801y6915702ay1983388366af7252@mail.gmail.com>
	 <E9E1F66D-8D15-4051-BA46-AF3F27AF0DC1@pobox.com>
	 <51d555c70612280833p202e57d1g511b8c240db4deed@mail.gmail.com>
	 <E3272A42-B28D-42A7-AE0C-8247E263FFED@pobox.com>
	 <51d555c70612281054w605707e1qdae50150e8eeaee6@mail.gmail.com>

------=_Part_104661_15778590.1167383640673
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

JFYI

The current GC-finalization Subsystem interface and intercommoning
communication described in  DevGuide. And now there are two finalization
implementation: multithreading one based on java thread and the other new
(created for GC5), based on 1 native thread.


On usual, multithreading implementation 1 "permanent" thread with normal
priority is created and this is enough. In heavy workloads additional treads
are created, but not many.

For example not more 4 under DeCapo on my machine. And it's pretty good on
HT P4.

Only in very stress situation more threads are created.


Also I know (by experiments) that 1 finalizer thread with any priority on
multi core machine is not enough.


Thanks
Pavel Afremov.


On 12/28/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:

> GCV5 does not need a custom finalizer. That is what would impact
> modularity.
> In fact, even that would not, if the interface were standardised.
> However, one would prefer GC's not to provide their own implementations
> for
> the interface since they are not fully aware of system load, and the GC
> dll
> can be unloaded in somewhat dynamic environments.
>
> All that has happened is that working on GCV5 has caused the current
> finalizer design/implementation to be reviewed.
>
> On 12/28/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> >
> > On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
> >
> > > On 12/28/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >>
> > >>
> > >>
> > >> >Well, we need a finalizer.  I agree that we're overthinking this a
> > >> >bit, but I'd like to understand why anyone thinks this belongs in
> > >> the
> > >> >GC - we keep claiming to do a modular VM, yet then do things like
> > >> >this... :)
> > >
> > >
> > > We can keep the minimal finalization implementation we have now ( a
> > > single
> > > high priority finalization thread ), and wait for use cases that
> > > need more.
> > > IMHO.
> > >
> > > The finalization subsystem is currently a VM component and the VM
> > > exposes
> > > the interface ( though minimal ) to the GC. This is the right way,
> > > and does
> > > not violate modularity or GC pluggability.
> >
> > So I don't understand what we are discussing - you seem to agree with
> > me that it belongs in the VM, and not the GC.
> >
> > This little discussion started because I was asking Xiaofeng why GCv5
> > had it's own finalization subsystem...
> >
> > geir
> >
> >
> >
> >
>
>

------=_Part_104661_15778590.1167383640673--