You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2006/12/10 04:47:11 UTC
[DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
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
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Xiao-Feng Li <xi...@gmail.com>.
Pavel, please see my message in another threads. Thanks, -xiaofeng
On 12/15/06, Pavel Pervov <pm...@gmail.com> wrote:
> Xiao Feng,
>
> Putting it the other way: what is wrong with DRLVM implementation, which
> required you to invent your own?
>
> Thanks,
> Pavel.
>
>
> On 12/15/06, Pavel Pervov <pm...@gmail.com> wrote:
> >
> > Xiao Feng,
> >
> > I didn't find any reason for replacing finalization and weak reference
> > implementation in your answer beside the fact that what you did is for GCv5
> > only.
> > Could you please, clarify it?
> >
> > Thanks,
> > Pavel.
> >
> > On 12/11/06, Xiao-Feng Li <xi...@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
> > > >
> > >
> >
> >
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Pavel Pervov <pm...@gmail.com>.
Xiao Feng,
Putting it the other way: what is wrong with DRLVM implementation, which
required you to invent your own?
Thanks,
Pavel.
On 12/15/06, Pavel Pervov <pm...@gmail.com> wrote:
>
> Xiao Feng,
>
> I didn't find any reason for replacing finalization and weak reference
> implementation in your answer beside the fact that what you did is for GCv5
> only.
> Could you please, clarify it?
>
> Thanks,
> Pavel.
>
> On 12/11/06, Xiao-Feng Li <xi...@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
> > >
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Pavel Pervov <pm...@gmail.com>.
Xiao Feng,
I didn't find any reason for replacing finalization and weak reference
implementation in your answer beside the fact that what you did is for GCv5
only.
Could you please, clarify it?
Thanks,
Pavel.
On 12/11/06, Xiao-Feng Li <xi...@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 <iv...@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 <xi...@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
> >
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Pavel Afremov <pa...@gmail.com>.
On 12/11/06, Ligang Wang <wa...@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 <wa...@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 <pa...@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 <xi...@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 <iv...@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 <xi...@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
> > > >
> > >
> >
> >
>
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Ligang Wang <wa...@gmail.com>.
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 <pa...@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 <xi...@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 <iv...@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 <xi...@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
> > >
> >
>
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Ivan Volosyuk <iv...@gmail.com>.
I'm not against work balancing system. I just have an opinion that the
threads used for finalization should run with higher priority. I don't
have strict motivation for this, just think that it will make us alike
the RI.
--
Ivan
On 12/11/06, Pavel Afremov <pa...@gmail.com> wrote:
> Did You mean high priority forever? Or tuned priority of finalizer thread?
>
> You wrote threads. How many threads You'd like to have?
>
>
>
> Pavel.
>
>
> On 12/11/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> >
> > On 12/11/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > 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.
> >
> > IMHO, I would prefer to have high priority finalizer threads.
> > --
> > Ivan
> >
>
>
--
Ivan
Intel Enterprise Solutions Software Division
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Pavel Afremov <pa...@gmail.com>.
Did You mean high priority forever? Or tuned priority of finalizer thread?
You wrote threads. How many threads You'd like to have?
Pavel.
On 12/11/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> On 12/11/06, Pavel Afremov <pa...@gmail.com> wrote:
> > 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.
>
> IMHO, I would prefer to have high priority finalizer threads.
> --
> Ivan
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 12/11/06, Pavel Afremov <pa...@gmail.com> wrote:
> 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.
IMHO, I would prefer to have high priority finalizer threads.
--
Ivan
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Pavel Afremov <pa...@gmail.com>.
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 <xi...@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 <iv...@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 <xi...@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
> >
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <iv...@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 <xi...@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
>
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <xi...@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
Re: [DRLVM][GCv5] patch for new LOS collector and finalizer/weakref support
Posted by Ivan Volosyuk <iv...@gmail.com>.
I have a question. You make some code duplication for finalizers
support in VM code. I would like to hear a reasons for that. Why not
to use existing code if it is effective or replace it with better one
if not?
--
Best regards,
Ivan
On 12/10/06, Xiao-Feng Li <xi...@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