On 1/1/07, Robin Garner <[EMAIL PROTECTED]> wrote:
Pavel Afremov wrote: > On 12/31/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: >> >> This looks good to me. Its close enough for the current state of >> drlvm. In >> other words, don't try to precisely replicate the performance numbers I >> collected from Sun 1.5.0. > > > > 1/50 ratio with usual work load for finalization system is not good, > because > it means 2% VM performance for main task. Let's evaluate following > abstraction. For example for finalization of some objects requires the same > time as for creation. These objects were generated during 10 seconds for > example. So machine will works with 2% performance for main task during 10 > seconds when finalizer is works. Finalization shouldn't stop main task, and > 2% of performance equals stopping. I think this is missing the point. Finalizers that run for a long time shouldn't be created.
Well put. Thank you.
- Finalizers should be run with high priority because memory (possibly large structures) can't be freed until they have completed.
I agree.
- Allowing the main application to make some progress while a badly written finalizer executes is good design practice
Exactly right.
I think this is the only criteria by which a finalization scheme can be evaluated. Whether the ratio is 1/50, 1/25, 1/200 is neither here nor there.
Absolutely correct.
From what I've seen to date, all the available DRLVM mechanisms are perfectly adequate,
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. 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.
and we should all get back to doing something productive.
Good point. As painful as it is, hammering out a workable design is actually productive. Robin, thanks for bearing with us through this process. As usual, your input is valuable.
best regards, Robin -- Robin Garner Dept. of Computer Science Australian National University http://cs.anu.edu.au/people/Robin.Garner/
-- Weldon Washburn Intel Enterprise Solutions Software Division
