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 Sat, 16 Dec 2006 01:26:19 GMT
All. It's good to see this discussion initiated. That's exactly what
we want. It would be a little frustrating to see our solution
committed without any response from the community. :-)  Anyway, we
submitted GCv5 finalizer solution for three reasons:

1. We don't want GCv5 submission to break any existing functionality,
and to keep the impact to minimum.
2 . We think it might be good idea to have more than one Finalizer
solutions in a JVM, as we have multiple JITs, multiple GCs, and
probably multiple other components as well.
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.

Explanations to 2.
  - It doesn't matter to have multiple solutions for one component
except for very strong reason.  Multiple solutions can be measured and
studied for different scenarios.
  - A Java thread finalizer solution is not a bad idea, and it would
be also desirable to have a native thread finalizer if it has many
advantages as described below. Different GCs can invoke different
finalizer solutions for its best performance, or same GC can invoke
different finalizer solutions at different times. This is feature
rather than a bug.
  - It is probably good for DRLVM to have the two finalizer solutions
to exercise its modularity design in the finalization subsystem. This
is one of the goals of DRLVM design.
  - It might be unreasonable to say one solution is absolutely better
than the other one, hence it is uncessary to quickly decide to keep
one and reject another one. The VM is evolving, so are its subsystems.

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.

It would be good to continue this discussion to reach an agreement on
the design. We probably can converge on one solution, or agree to keep
two solutions.

Thanks,
xiaofeng


On 12/16/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 12/15/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >
> > Hi.
> >
> >
> >
> > Weldon.
> >
> > Could You be so kind to read mail list <<[DRLVM][GCv5] patch for new LOS
> > collector and finalizer/weakref support>>.
>
>
> Yes, I recall your comments.  I decided that since GCV5 finalizer does not
> disrupt existing finalizer to go ahead and do the commit.  Its is fairly
> simple to commit compensating changes if we decide to eliminate GCV5
> finalizer.
>
> I tried to start discussion in it, during patch review process. But it was
> > stopped  by Ligang Wang, because, as I understand, the "new" solution is
> > not
> > "real" solution (Work Balance Subsystem was turned of there, for
> > example), "it's
> > only a start, and at the moment only for GCv5". So it's a temporary
> > solution.
>
>
> The discussion needs to be restarted.  Xiao Feng, can you reply to the
> questions?
>
> So I have several question for "new" scheme, and when it will be solved, we
> > will be ready to discuss a future development of finalization system. I
> > will
> > be glad to share my ideas in this area.
> >
> >
> >
> > Salikh.
> >
> > You can find prepared by my patch
> > HARMONY-2230<https://issues.apache.org/jira/browse/HARMONY-2230>,
> > which contains described by you feature, implemented in more correct way,
> > as
> > I think.
> >
> >
> >
> > Thanks.
> >
> > Pavel Afremov.
> >
> >
> >
> >
> > On 12/15/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > >
> > > Weldon Washburn wrote:
> > > > Harmony-2560 adds a second finalizer implementation to the Apache code
> > > > base.
> > >
> > > Speaking of finalizers design, I would like to note that HARMONY-1952
> > > has a proof-of-concept idea of refining the current weak references
> > > design to prevent running java code from a vm_hint_finalize() callback,
> > > which may happen anywhere in the user code.
> > >
> > > > But "build
> > > > test" does not exercise finalizers to any degree.
> > >
> > > Not true.
> > > $ grep -lr finalize vm/tests/
> > > vm/tests/kernel/java/lang/RuntimeAdditionalSupport2.java
> > > vm/tests/kernel/java/lang/RuntimeAdditionalTest40.java
> > > vm/tests/kernel/java/lang/RuntimeAdditionalTest43.java
> > > vm/tests/kernel/java/lang/RuntimeTest2.java
> > > vm/tests/kernel/java/lang/SystemExtensionTest.java
> > > vm/tests/smoke/exception/FinalizeStackTest.java
> > > vm/tests/smoke/gc/Finalizer.java
> > > vm/tests/smoke/gc/FinAlloc.java
> > > vm/tests/smoke/gc/RunFinalizersOnExitTest.java
> > > vm/tests/smoke/gc/SynchronizedFinilazersTest.java
> > > vm/tests/smoke/stress/Finalizer.java
> > > vm/tests/smoke/thread/InfiniteFinalizer.java
> > >
> > > But then, I believe that 'build test' run without any additional
> > switches
> > > will not exercise any of GCv5.
> > >
> > > > In any case, long term we need just one finalizer design and
> > > > implementation.  I would like to see a discussion on the merits of
> > each
> > > of
> > > > the finalizer approaches.  It would be good to pick one approach
> > within
> > > one
> > > > week.  Then we can clean up the code to reduce confusion.
> > >
> > > I guess you mean "it would be good if someone submits a _cleaned code_
> > > within one week so that we could make a decision" ?
> > >
> > >
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>

Mime
View raw message