harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Tue, 19 Dec 2006 01:41:21 GMT
On 12/19/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.

Thanks, Pavel. I agree that the GCv5 patch for finalization is not
perfect. This is expected. Since Harmony is open in development, it's
actually unexpected to see a perfect solution in a patch without prior
discussions. :-)

Thanks,
xiaofeng

>
> 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
View raw message