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][gcv5] finalizer design
Date Wed, 20 Dec 2006 09:51:43 GMT
Hello.

Xiao-Feng,  LiGang Wang, could You help me, please. I can't find where native
finalizer thread associated with java Thread object. Where is it? What is
happened when Thread.currentThread() is called in finalize method?



Also could You hint me with what command string you run GC v5? It's very
interesting for me to run it.



Thank You in advance.

Pavel Afremov.


On 12/19/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> Absolutely agree.
>
>
>
> Especially, take in account the fact, that "native" finalizer thread
> should be associated with java thread.
>
>
>
> Hm…Could anyone found association code. It's strange but can't find it.
> Where is finalizer (refderence) "native" thread associated with java thread
> object?
>
> BR
> Pavel Afremov.
>
>
> On 12/19/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >
> > 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