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:22:51 GMT
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?

That's what I believe. Or you can give some reason why you don't believe.

> [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?

I don't think so. I think it's easier actually because it removes the
redundant boundary crossings in implementation. The boundary crossings
are really harder for porting because the developer needs to care
about the gc enable/disable and object handle bookkeeping things.

The Java finalization system depends on the native threading in VM.
The native finalization implementation depends on the same thing. It
actually depends less on external resource compared to the Java
finalization, hence to be more portable.

Thanks,
xiaofeng

> geir
>

Mime
View raw message