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
