On 12/14/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.
Salikh, thanks for pointing this out. The worry that the existing finalizer is disrupted by gcv5 finalizer looks to be unfounded.
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" ? Actually what I mean is that I would like to see a design discussion. Now
that I think about it, its probably longer than one week to discuss finalizer designs. -- Weldon Washburn Intel Enterprise Solutions Software Division
