On 1/2/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Yes with one reservation. I'd like to see the existing DRLVM mechanisms hard coded for just one finalizer thread for now. And that no finalizer code be committed that suspends/resumes java app threads. The intention is to reduce debug confusion.
Unclear and unfounded. No existing test was run by Weldon on different finalization schemes, and no result was published. Unsuitable date was named as noise, or ignored. Also I see many visions that one scheme is better than other, without any competitive comparison.
We have plenty of problems in the threading subsystem that need sorting out. Adding finalizer threads that come and go along with starting/stopping java threads based on finalization load factor is way too confusing.
Threading system is separate component, and can't and shouldn't be confused by Finalization system. But I see that finalization system design was declared as source of threading system bug without any reasons. Before said, it should be checked by finalization turn off flag. I'm sorry, but I agree with Robin that discussing is not productive. Sorry again for harsh words, but it's true. To continue we should choose a strategy: copy existing scheme or developed new one, which will be optimized for defined set of applications. After that anybody can propose new scheme, with results of DRLVM on different tests with different finalization schemes. After that We can discuss it, and choose a way how implement the best finalization scheme. Pavel Afremov.
