On 12/11/06, Ligang Wang <[EMAIL PROTECTED]> wrote:
...2. The finalizer thread is 3 levels lower in priority than the highest one. It doesn't block the VM.
Sorry. I miss -3 in definition. So It's not highest, but is high enough, because 10 – 3 = 7 is more than 5 (normal priority). In this case usual user code is not blocked, but starts work slower. If it's temporary solution it may be OK, but should be improved in future, I think. Thank you for your clarifications. Pavel Afremov On 12/11/06, Ligang Wang <[EMAIL PROTECTED]> wrote:
Pavel, thanks for your interests. Probably I need to clarify again that the GCv5 finalization code is not supposed to be the best solution nor better than the existing one. As Xiao-Feng said, it's only a start, and at the moment only for GCv5. For your questions: 1. For GCv5, we think a native solution is good enough at the moment. We might consider a Java thread solution when appropriate. 2. The finalizer thread is 3 levels lower in priority than the highest one. It doesn't block the VM. 3. Yes, to introduce dynamic load balance is better. We will improve our implementation along this way. 4. Thanks for the info. Yes, gc.SynchronizedFinalizerTest is tested, and passed with more native threads specified. We need introduce dynamic mechanism to improve our solution. On 12/11/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > Hi I have several questions about finalizer & ref in vm part. > > 1. For what reason is native finalizer thread required? I thought > that > native and java threads is equal for finalization purpose. Also Java > thread > can uses future "magic" technology for extra performance. > > 2. Finalizer thread starts works with highest priority, doesn't it? > Is > it right? Why VM should stops when any finalization works is required? > > 3. In Finalization system now there is Work Balance Mechanism which > tunes performance of finalization. When many finalizable object are > allocated and queue for finalization isn't empty this mechanism increase > performance of finalization (more detailed description see in dev guide). > I > can't found usage of Work Balance Subsystem in this patch. Maybe it would > be > better to use WBS instead high priority forever for finalizer thread. > > 4. Did you check you patch with gc.SynchronizedFinalizerTest? Could > play with parameters in this synthetic stress test to provide reliability > of > finalization system for any work load. > > > > Thank you in advance > > Pavel Afremov. > > > On 12/11/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > Ivan, thanks for your quick review. Your two questions are good. > > Basically the patches are for GCv5 only since we don't want to impact > > any existing Harmony functionalities when GCv5 is not on. :-) At least > > we want to control the impact to be minimal at the moment until we > > have enough confidence. And yes, I agree with you that the coding > > style should be improved, and actually that's in our plan. We'd like > > to evolve the code base and probably with contributions from other > > participants. The patches are supposed to be a start for further > > improvements. > > > > Thanks, > > xiaofeng > > > > On 12/11/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > > One more question. I have taken a quick glance on implementation. I > > > see, some code duplication in process_weak_references, > > > process_soft_references, process_phantom_references... Is this it? Why > > > not create a more general function which will deal with all of the > > > reference types? > > > -- > > > Ivan > > > > > > On 12/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > Hi, two GCv5 patches were submitted, one for GCv5 LOS collector > > > > developed by Ji Qi, the other for finalizer and weak reference > support > > > > developed by LiGang Wang. Both patches are only for GCv5, having no > > > > impact on other parts. They are tested on Windows and Linux 32bit. > > > > Harmony committer please helps to integrate them into SVN at early > > > > convenience. > > > > > > > > They are at: > > > > https://issues.apache.org/jira/browse/HARMONY-2509 > > > > https://issues.apache.org/jira/browse/HARMONY-2560 > > > > > > > > In order to save committer's time, the patches are built in a way > that > > > > the second one 2560 is based on 2509. So they can be patched in > order > > > > and then committed at once. > > > > > > > > Thanks, > > > > xiaofeng > > > > > > > > > > > > > -- > > > Ivan > > > Intel Enterprise Solutions Software Division > > > > > > >
