You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/11/02 22:49:02 UTC
[drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Pavel,
I just now looked at your latest H1558 patch. Unfortunately the patch won't
cleanly apply. It can not be committed yet. In any case, 1558 seems to
basically reformat the interfaces that access class specific info. It looks
like a bunch of cosmetic changes. No change in underlying algorithms. Is
this correct?
Aleksey, Pavel,
Do you know if there are interdependencies between H1558 and H2000? In any
case, I believe H1558 should be committed first. And H2000 will have to
pick up the pieces.
Everyone,
Comments? Suggestions?
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning
class.h (JIRA H1558)
Posted by Gregory Shimansky <gs...@gmail.com>.
Weldon Washburn wrote:
> 1558 pass the pre-commit "build test" on my windows laptop. I have not
> done
> a post-commit clean "svn checkout", build, build test. Mostly because
> build
> test makes my laptop unusable for over an hour. It would be good if
> someone
> can double verify the windows build is OK since 1558 commit was one hundred
> twenty files.
Don't worry, you would've known if you broke win32 by now :)
I've verified the build on winxp laptop and 2003 server with HT. Tests
seem to be working as before the patch. That is gc.LOS hanging on XP,
some problems with threading described in HARMONY-2070 and
java.lang.ThreadTest failing.
--
Gregory
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Weldon Washburn <we...@gmail.com>.
1558 pass the pre-commit "build test" on my windows laptop. I have not done
a post-commit clean "svn checkout", build, build test. Mostly because build
test makes my laptop unusable for over an hour. It would be good if someone
can double verify the windows build is OK since 1558 commit was one hundred
twenty files.
On 11/9/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
> Great. Thanks Weldon. Does this mean that it is to be verified on Windows?
>
> On 11/8/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > 1558 has been committed. It took two commits since I forgot to "svn
> add"
> > 4
> > files. All in all, one hundred and twenty one files were committed.
> >
> > Following the commit(s), I did an "rm -rf trunk", svn update, build.sh,
> "
> > build.sh test" on my linux box. Everything seems to work OK.
> >
> >
> >
> >
> > On 11/8/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > > so, how did it go?
> > >
> > > Weldon Washburn wrote:
> > > > On 11/7/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > >>
> > > >> On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> > > >> > H1558 has been a big battle to get it into committable shape. I
> > > would
> > > >> > really like to commit it first. (In fact, Pavel and I are
> working
> > > >> on it
> > > >> > right now!)
> > > >>
> > > >> The patch in HARMONY-1558 is huge and often is broken by new VM
> > > commits.
> > > >> Shall
> > > >> we make a freeze on VM commits to allow this patch it? Maintaining
> so
> > > >> many
> > > >> code changes is probably not an easy task.
> > > >>
> > > >> I've tried to apply it today and it doesn't apply cleanly (no
> > surprise,
> > > 5
> > > >> days
> > > >> passed since the last update). I think some cooperation between VM
> > > >> committers
> > > >> is required to allow this patch to be finally integrated into the
> > code.
> > > >>
> > > >> We should either agree to let it in or let it die. I support the
> > first
> > > >> option.
> > > >>
> > > >> Weldon, Geir, what do you think?
> > > >
> > > >
> > > > Pavel and I will work on 1558 in the next 12 hours. Hopefully
> > > > we will commit it very soon. It has been a very difficult patch to
> > > apply
> > > > for all the reasons you describe. It would be appreciated if you
> can
> > > hold
> > > > off applying any patches that might modify the same files as 1558.
> > > >
> > > > --
> > > >> Gregory Shimansky, Intel Middleware Products Division
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Rana Dasgupta <rd...@gmail.com>.
Great. Thanks Weldon. Does this mean that it is to be verified on Windows?
On 11/8/06, Weldon Washburn <we...@gmail.com> wrote:
>
> 1558 has been committed. It took two commits since I forgot to "svn add"
> 4
> files. All in all, one hundred and twenty one files were committed.
>
> Following the commit(s), I did an "rm -rf trunk", svn update, build.sh, "
> build.sh test" on my linux box. Everything seems to work OK.
>
>
>
>
> On 11/8/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > so, how did it go?
> >
> > Weldon Washburn wrote:
> > > On 11/7/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > >>
> > >> On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> > >> > H1558 has been a big battle to get it into committable shape. I
> > would
> > >> > really like to commit it first. (In fact, Pavel and I are working
> > >> on it
> > >> > right now!)
> > >>
> > >> The patch in HARMONY-1558 is huge and often is broken by new VM
> > commits.
> > >> Shall
> > >> we make a freeze on VM commits to allow this patch it? Maintaining so
> > >> many
> > >> code changes is probably not an easy task.
> > >>
> > >> I've tried to apply it today and it doesn't apply cleanly (no
> surprise,
> > 5
> > >> days
> > >> passed since the last update). I think some cooperation between VM
> > >> committers
> > >> is required to allow this patch to be finally integrated into the
> code.
> > >>
> > >> We should either agree to let it in or let it die. I support the
> first
> > >> option.
> > >>
> > >> Weldon, Geir, what do you think?
> > >
> > >
> > > Pavel and I will work on 1558 in the next 12 hours. Hopefully
> > > we will commit it very soon. It has been a very difficult patch to
> > apply
> > > for all the reasons you describe. It would be appreciated if you can
> > hold
> > > off applying any patches that might modify the same files as 1558.
> > >
> > > --
> > >> Gregory Shimansky, Intel Middleware Products Division
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Weldon Washburn <we...@gmail.com>.
1558 has been committed. It took two commits since I forgot to "svn add" 4
files. All in all, one hundred and twenty one files were committed.
Following the commit(s), I did an "rm -rf trunk", svn update, build.sh, "
build.sh test" on my linux box. Everything seems to work OK.
On 11/8/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> so, how did it go?
>
> Weldon Washburn wrote:
> > On 11/7/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >>
> >> On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> >> > H1558 has been a big battle to get it into committable shape. I
> would
> >> > really like to commit it first. (In fact, Pavel and I are working
> >> on it
> >> > right now!)
> >>
> >> The patch in HARMONY-1558 is huge and often is broken by new VM
> commits.
> >> Shall
> >> we make a freeze on VM commits to allow this patch it? Maintaining so
> >> many
> >> code changes is probably not an easy task.
> >>
> >> I've tried to apply it today and it doesn't apply cleanly (no surprise,
> 5
> >> days
> >> passed since the last update). I think some cooperation between VM
> >> committers
> >> is required to allow this patch to be finally integrated into the code.
> >>
> >> We should either agree to let it in or let it die. I support the first
> >> option.
> >>
> >> Weldon, Geir, what do you think?
> >
> >
> > Pavel and I will work on 1558 in the next 12 hours. Hopefully
> > we will commit it very soon. It has been a very difficult patch to
> apply
> > for all the reasons you describe. It would be appreciated if you can
> hold
> > off applying any patches that might modify the same files as 1558.
> >
> > --
> >> Gregory Shimansky, Intel Middleware Products Division
> >>
> >
> >
> >
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning
class.h (JIRA H1558)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
so, how did it go?
Weldon Washburn wrote:
> On 11/7/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Friday 03 November 2006 19:18 Weldon Washburn wrote:
>> > H1558 has been a big battle to get it into committable shape. I would
>> > really like to commit it first. (In fact, Pavel and I are working
>> on it
>> > right now!)
>>
>> The patch in HARMONY-1558 is huge and often is broken by new VM commits.
>> Shall
>> we make a freeze on VM commits to allow this patch it? Maintaining so
>> many
>> code changes is probably not an easy task.
>>
>> I've tried to apply it today and it doesn't apply cleanly (no surprise, 5
>> days
>> passed since the last update). I think some cooperation between VM
>> committers
>> is required to allow this patch to be finally integrated into the code.
>>
>> We should either agree to let it in or let it die. I support the first
>> option.
>>
>> Weldon, Geir, what do you think?
>
>
> Pavel and I will work on 1558 in the next 12 hours. Hopefully
> we will commit it very soon. It has been a very difficult patch to apply
> for all the reasons you describe. It would be appreciated if you can hold
> off applying any patches that might modify the same files as 1558.
>
> --
>> Gregory Shimansky, Intel Middleware Products Division
>>
>
>
>
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Weldon Washburn <we...@gmail.com>.
On 11/7/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> > H1558 has been a big battle to get it into committable shape. I would
> > really like to commit it first. (In fact, Pavel and I are working on it
> > right now!)
>
> The patch in HARMONY-1558 is huge and often is broken by new VM commits.
> Shall
> we make a freeze on VM commits to allow this patch it? Maintaining so many
> code changes is probably not an easy task.
>
> I've tried to apply it today and it doesn't apply cleanly (no surprise, 5
> days
> passed since the last update). I think some cooperation between VM
> committers
> is required to allow this patch to be finally integrated into the code.
>
> We should either agree to let it in or let it die. I support the first
> option.
>
> Weldon, Geir, what do you think?
Pavel and I will work on 1558 in the next 12 hours. Hopefully
we will commit it very soon. It has been a very difficult patch to apply
for all the reasons you describe. It would be appreciated if you can hold
off applying any patches that might modify the same files as 1558.
--
> Gregory Shimansky, Intel Middleware Products Division
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> H1558 has been a big battle to get it into committable shape. I would
> really like to commit it first. (In fact, Pavel and I are working on it
> right now!)
The patch in HARMONY-1558 is huge and often is broken by new VM commits. Shall
we make a freeze on VM commits to allow this patch it? Maintaining so many
code changes is probably not an easy task.
I've tried to apply it today and it doesn't apply cleanly (no surprise, 5 days
passed since the last update). I think some cooperation between VM committers
is required to allow this patch to be finally integrated into the code.
We should either agree to let it in or let it die. I support the first option.
Weldon, Geir, what do you think?
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Weldon Washburn <we...@gmail.com>.
H1558 has been a big battle to get it into committable shape. I would
really like to commit it first. (In fact, Pavel and I are working on it
right now!)
On 11/3/06, Aleksey Ignatenko <al...@gmail.com> wrote:
>
> Weldon,
> Merge will be required for one of these JIRAs. It depends on what JIRA is
> going to be commited first. To avoid redundant work I suggest to announce
> what JIRA is going to be commited first.
>
> Aleksey.
>
>
> On 11/3/06, Pavel Pervov <pm...@gmail.com> wrote:
> >
> > Weldon,
> >
> > Basically, yes. Algorithms were indeed changed, where interfaces
> dictated
> > so. Also, several places were optimized out as dead code.
> >
> > Pavel.
> >
> > On 11/3/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > Pavel,
> > >
> > > I just now looked at your latest H1558 patch. Unfortunately the patch
> > > won't
> > > cleanly apply. It can not be committed yet. In any case, 1558 seems
> > to
> > > basically reformat the interfaces that access class specific info. It
> > > looks
> > > like a bunch of cosmetic changes. No change in underlying
> > algorithms. Is
> > > this correct?
> > >
> > > Aleksey, Pavel,
> > >
> > > Do you know if there are interdependencies between H1558 and
> H2000? In
> > > any
> > > case, I believe H1558 should be committed first. And H2000 will have
> to
> > > pick up the pieces.
> > >
> > > Everyone,
> > >
> > > Comments? Suggestions?
> > >
> > > --
> > > Weldon Washburn
> > > Intel Enterprise Solutions Software Division
> > >
> > >
> >
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Aleksey Ignatenko <al...@gmail.com>.
Weldon,
Merge will be required for one of these JIRAs. It depends on what JIRA is
going to be commited first. To avoid redundant work I suggest to announce
what JIRA is going to be commited first.
Aleksey.
On 11/3/06, Pavel Pervov <pm...@gmail.com> wrote:
>
> Weldon,
>
> Basically, yes. Algorithms were indeed changed, where interfaces dictated
> so. Also, several places were optimized out as dead code.
>
> Pavel.
>
> On 11/3/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Pavel,
> >
> > I just now looked at your latest H1558 patch. Unfortunately the patch
> > won't
> > cleanly apply. It can not be committed yet. In any case, 1558 seems
> to
> > basically reformat the interfaces that access class specific info. It
> > looks
> > like a bunch of cosmetic changes. No change in underlying
> algorithms. Is
> > this correct?
> >
> > Aleksey, Pavel,
> >
> > Do you know if there are interdependencies between H1558 and H2000? In
> > any
> > case, I believe H1558 should be committed first. And H2000 will have to
> > pick up the pieces.
> >
> > Everyone,
> >
> > Comments? Suggestions?
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Pavel Pervov <pm...@gmail.com>.
Weldon,
Basically, yes. Algorithms were indeed changed, where interfaces dictated
so. Also, several places were optimized out as dead code.
Pavel.
On 11/3/06, Weldon Washburn <we...@gmail.com> wrote:
>
> Pavel,
>
> I just now looked at your latest H1558 patch. Unfortunately the patch
> won't
> cleanly apply. It can not be committed yet. In any case, 1558 seems to
> basically reformat the interfaces that access class specific info. It
> looks
> like a bunch of cosmetic changes. No change in underlying algorithms. Is
> this correct?
>
> Aleksey, Pavel,
>
> Do you know if there are interdependencies between H1558 and H2000? In
> any
> case, I believe H1558 should be committed first. And H2000 will have to
> pick up the pieces.
>
> Everyone,
>
> Comments? Suggestions?
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Aleksey Ignatenko <al...@gmail.com>.
I agree with Pavel, but I want hear conformation about H1558 is commited
first.
Aleksey.
On 11/3/06, Pavel Pervov <pm...@gmail.com> wrote:
>
> And yes, patches for H1558 and H2000 will most certainly conflict. I hope,
> Aleksey will agree on rebasing his patch after my changes will be
> committed
> at last.
>
> Regards,
> Pavel.
>
>
> On 11/3/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Pavel,
> >
> > I just now looked at your latest H1558 patch. Unfortunately the patch
> > won't
> > cleanly apply. It can not be committed yet. In any case, 1558 seems
> to
> > basically reformat the interfaces that access class specific info. It
> > looks
> > like a bunch of cosmetic changes. No change in underlying
> algorithms. Is
> > this correct?
> >
> > Aleksey, Pavel,
> >
> > Do you know if there are interdependencies between H1558 and H2000? In
> > any
> > case, I believe H1558 should be committed first. And H2000 will have to
> > pick up the pieces.
> >
> > Everyone,
> >
> > Comments? Suggestions?
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Posted by Pavel Pervov <pm...@gmail.com>.
And yes, patches for H1558 and H2000 will most certainly conflict. I hope,
Aleksey will agree on rebasing his patch after my changes will be committed
at last.
Regards,
Pavel.
On 11/3/06, Weldon Washburn <we...@gmail.com> wrote:
>
> Pavel,
>
> I just now looked at your latest H1558 patch. Unfortunately the patch
> won't
> cleanly apply. It can not be committed yet. In any case, 1558 seems to
> basically reformat the interfaces that access class specific info. It
> looks
> like a bunch of cosmetic changes. No change in underlying algorithms. Is
> this correct?
>
> Aleksey, Pavel,
>
> Do you know if there are interdependencies between H1558 and H2000? In
> any
> case, I believe H1558 should be committed first. And H2000 will have to
> pick up the pieces.
>
> Everyone,
>
> Comments? Suggestions?
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division