On Sunday 24 December 2006 16:23 Weldon Washburn wrote: > Very interesting. Please tell me if the following is correct. Without > WBS, finalizing objects falls further and further behind because > finalization thread(s) are unable to grab enough of the CPU(s) to keep up. > Instead of increasing the priority of the finalization thread(s), WBS takes > the approach of increasing the number of finalization threads. The net > effect is to increase the rate of finalization by diluting the OS ready > queue. > > Does the following alternative design make sense? Assume the OS/VM porting > layer allows the VM to change an OS thread's priority appropriately. > During VM boot, query the OS to determine the number of CPUs in the box and > create one finalizer thread for each CPU. Never create additional > finalizer threads. Boost the priority of the finalizer threads above the > level of Java app threads (but probably below real time priority.) Note > that all of this is orthogonal to "native" vs. "java" finalizer threads.
I like this approach. It probably covers all mentioned problems except for the fundamental finalizers problem of long running (never ending) finalize() methods. -- Gregory
