harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Date Mon, 11 Dec 2006 13:22:56 GMT
On 12/11/06, Ligang Wang <wanglg9711@gmail.com> 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 <wanglg9711@gmail.com> 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 <pavel.n.afremov@gmail.com> 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 <xiaofeng.li@gmail.com> 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 <ivan.volosyuk@gmail.com> 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 <xiaofeng.li@gmail.com> 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
> > > >
> > >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message