On 1/1/07, Robin Garner wrote: > Pavel Afremov wrote: > > On 12/31/06, Weldon Washburn 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