harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Mon, 18 Dec 2006 12:50:13 GMT


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