harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Tue, 19 Dec 2006 01:05:52 GMT
I would suggest keeping both( native and java finalizer threads )around for
now  through a unified interface. I am not sure I followed why it is a
requirement for GCv5 to support the work balance subsystem. But it is true
that it cannot ultimately rely on a single high priority thread for
finalization for it  to avoid starvation, prevent denial of service, etc.

Implementing finalizer threads in java was a DRLVM choice some time back,
based on some boundary crossing efficiency concerns for finalizer threads.
>From testing over quite a long period, it seems stable. Unless proved
different, or unless we do a significantly better performing VM threadpool
implemenation around GCV5, I see no reason why it should not be reused just
because the threads are in Java.




On 12/18/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> On 12/18/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >
> >
> > But don't you then make it harder to port?
> >
> >
>
> It's makes porting a bit harder, but not very, I think. The main point now
> to avoid regression. I think GC v5 should support Work Balance Subsystem,
> or
> something like it before it becomes main GC for DRLVM. Also GC v5 should
> works with "java" implementation of finalization system correctly, in any
> case VM and GC implementations should be independent on each other.
>
>
>
> BR
>
> Pavel Afremov.
>
>
> On 12/18/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >
> >
> >
> > Xiao-Feng Li wrote:
> >
> > [SNIP]
> >
> > > 3 . We think a native thread Finalizer solution is better than a Java
> > > thread solution. Since the Java thread actually runs in a native
> > > thread, we don't need the extra wrapper.
> >
> > Really?
> >
> > [SNIP]
> >
> > >
> > > Explanations to  3 .
> > >  - In Java finalizer thread implementation, there exists potential
> > > circular dependence between the Java thread startup and JVM
> > > bootstrapping. The bootstrapping issues or bugs with Java code in VM
> > > were discussed more than once.
> > >  - In Java finalizer thread implementation, there are rounds of
> > > redundant steps to do finalization with Java thread. In existing Java
> > > thread implementation, to execute the finalizers, VM native calls Java
> > > method startFinalization to wakeup finalizer threads. The finalizer
> > > Java threads call a native method doFinalization to excute the
> > > finalizers. This native method accesses native queue and calls Java
> > > finalizer method again. With a native thread finalizer, it simply
> > > calls the Java finalizer directly without all other boundary
> > > crossings.
> > >  - A java finalizer thread finally maps to a native thread managed by
> > > VM. This extra mapping is unnecessary.
> > >  - Finalizer threads are VM internal entities. VM may want to
> > > schedule it as it wants for load balance or helper threading. This is
> > > much easier with the direct native threads.
> > >  - With native thread finalizer, we can share the same thread pool
> > > with other VM components such as GC, etc. This helps to manage the
> > > system overall performance and scalability, and it's easier.
> > >  - DRLVM is in written in C++, its components interact through native
> > > interfaces. It is natural for VM core components written in native
> > > code.
> >
> > But don't you then make it harder to port?
> >
> >
> > geir
> >
>
>

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