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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> On 12/15/06, Pavel Afremov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
