harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Mon, 18 Dec 2006 05:52:40 GMT
Robin,
If its handy, could you summarize the finalizer/GC interface in Jikes for
us?  Also, do you happen to know the design problems in Jikes finalizers?
This would help us get a better understanding of how to design a java-based
finalizer.


On 12/17/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>
> Naively, I would have thought the design of finalization and GC were
> orthogonal.
>
> In terms of interfaces,
> a) VM informs GC upon creation that an object has a finalizer (and needs
> notifying when it becomes unreachable).
> b) GC informs VM (and forwards or marks object) when an object with a
> finalizer becomes unreachable (VM is then responsible for keeping it alive
> until finalization is complete).
>
> What happens after (b) is outside the scope of the GC, surely ?  And isn't
> how the GC deals with the information provided by (a) outside the scope of
> the VM ?
>
> signed,
> Puzzled, in Canberra.
>
> > 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
> >>
> >>
> >
>
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message