harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm] finalizer design questions
Date Fri, 29 Dec 2006 09:14:00 GMT
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
> >
> >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message