You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Rana Dasgupta <rd...@gmail.com> on 2006/10/12 21:55:28 UTC
[drlvm] IPF functionality
Hi,
There is incomplete support for IPF platforms in the DRLVM codebase, as
many may have seen. It would be nice to complete it. There are a couple of
issues on how to start this. IPF specific changes are likely to be quite
significant, including changes in the JIT, garbage collector(s), exception
handling model and other core VM areas, as well as IPF functionality and
performance specific tests. Given the invasive nature of these changes, it
seems to me that we could:
1. Create a seperate branch in svn and do all IPF work there. JIRA
submissions could be clearly marked [IPF]. Since most committers may not
have access to IPF paltforms ( a safe guess :-) ) right now, they could help
by just applying the patches and committing the IPF submissions into the
branch( without testing, but certainly code review comments and IPF
verification, if possible are welcome ). It would be the responsibility of
the few IPF code contributors to keep their branch tested and stable. This
means some additional work for the committers, but worse..at some point when
the IPF port is completed, if we want to merge the code back into the trunk,
that will not be a small task.
2. Not create a seperate branch. Committers ( at least those without access
to IPF ) could verify on their favorite IA32 or EM64T platform before
committing the IPF related changes also into trunk. This way, we are not
defering the merge problem, but overall everyone is impacted because there
will be more commits into the trunk, more conflicts, and things will be
somewhat slower. This is somewhat the model that we are following with
EM64T specific submissions now, but IPF specific changes and submissions are
expected to be of higher volume.
3. Follow 1, but always keep IPF as a special platform on a seperate
branch. Never merge back. As IPF functionality is more complete and
committers get access to IPF machines, we just start testing more
rigorously before commiting IPF code and also start running automated tests
( whatever we are doing in the main branch ). IPF distributions can be
rolled out of its own branch.
However we do it could be a model for porting to other future platforms (
let's say Mac ) as well. Comments or other ideas?
Thanks,
Rana
Re: [drlvm] IPF functionality
Posted by Oleg Khaschansky <ol...@gmail.com>.
I'd like to mention that the vast majority of the classlib code is
buildable and executable on IPF without any additional changes. The
one exception I know, is assembler code from
luni module which supports threading. I think it could be sorted out
in the same way as it was done for em64t. Also the ant build should be
modified and proper binaries added to the depends.
So, speaking about classlib, I am +1 for the main trunk.
On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Egor Pasko wrote:
> > On the 0x201 day of Apache Harmony Rana Dasgupta wrote:
> >> I think that over time, we will start seeing IPF specific code files
> >> appearing ... eg., quite a different jit, IPFhelpers.cpp,
> >> IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
> >> That is my impression of how most IPF ports go. Even in the main codebase
> >> they will virtually be a branch. While they are architecturally quite
> >> seperate, they are seperate enough to maybe not cause a lot of conflict.
> >> So the question is really one of how we want to manage this, and if we want
> >> to consider the IPF work as mainline work or secondary. That is my
> >> understanding. I am fine with Geir's choice, and his comment about it being
> >> easier to manage one codeline makes sense. But I would request leaving this
> >> open for some more comments from the jit guys and others before we decide.
> >
> > Actually, I am +1 to Geir. Let's face the problems not earlier than
> > they appear. When Geir becomes overwhelmed with IPF patches, we may
> > reconsider it to a separate branch. Premature optimization is the root
> > of all evil :)
>
> Unless you are a JIT
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Egor Pasko wrote:
> On the 0x201 day of Apache Harmony Rana Dasgupta wrote:
>> I think that over time, we will start seeing IPF specific code files
>> appearing ... eg., quite a different jit, IPFhelpers.cpp,
>> IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
>> That is my impression of how most IPF ports go. Even in the main codebase
>> they will virtually be a branch. While they are architecturally quite
>> seperate, they are seperate enough to maybe not cause a lot of conflict.
>> So the question is really one of how we want to manage this, and if we want
>> to consider the IPF work as mainline work or secondary. That is my
>> understanding. I am fine with Geir's choice, and his comment about it being
>> easier to manage one codeline makes sense. But I would request leaving this
>> open for some more comments from the jit guys and others before we decide.
>
> Actually, I am +1 to Geir. Let's face the problems not earlier than
> they appear. When Geir becomes overwhelmed with IPF patches, we may
> reconsider it to a separate branch. Premature optimization is the root
> of all evil :)
Unless you are a JIT
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x201 day of Apache Harmony Rana Dasgupta wrote:
> I think that over time, we will start seeing IPF specific code files
> appearing ... eg., quite a different jit, IPFhelpers.cpp,
> IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
> That is my impression of how most IPF ports go. Even in the main codebase
> they will virtually be a branch. While they are architecturally quite
> seperate, they are seperate enough to maybe not cause a lot of conflict.
> So the question is really one of how we want to manage this, and if we want
> to consider the IPF work as mainline work or secondary. That is my
> understanding. I am fine with Geir's choice, and his comment about it being
> easier to manage one codeline makes sense. But I would request leaving this
> open for some more comments from the jit guys and others before we decide.
Actually, I am +1 to Geir. Let's face the problems not earlier than
they appear. When Geir becomes overwhelmed with IPF patches, we may
reconsider it to a separate branch. Premature optimization is the root
of all evil :)
> > On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > > How about trying to do in main line for now, reserving branch until
> > > needed?
> > >
> > > We'd agree that committers put in the patches and test on supported
> > > platforms (not IPF) and those doing the IPF work test and adjust as
> > > necessary.
> > >
> > > That way, we at least try to keep one codeline that we know works. It
> > > also would "restrict" the freedom of the IPF contributions to stay
> > > within the bounds of the mainline code, and in the event an architecture
> > > change is needed to support IPF that would affect other platforms, we
> > > can talk together.
> > >
> > > I volunteer to help with the IPF patches.
> > >
> > >
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> I think that over time, we will start seeing IPF specific code files
> appearing ... eg., quite a different jit, IPFhelpers.cpp,
> IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
> That is my impression of how most IPF ports go. Even in the main codebase
> they will virtually be a branch. While they are architecturally quite
> seperate, they are seperate enough to maybe not cause a lot of conflict.
> So the question is really one of how we want to manage this, and if we want
> to consider the IPF work as mainline work or secondary.
I think it's secondary from the POV of availability, where x86 is
ubiquitous, not in importance as a platform.
> That is my
> understanding. I am fine with Geir's choice, and his comment about it being
> easier to manage one codeline makes sense. But I would request leaving this
> open for some more comments from the jit guys and others before we decide.
My point is that we don't need a "decision" to get moving forward. We
can just move forward with the status quo, and if we run into a problem,
then we can decide what to do...
geir
>
> Thanks,
> Rana
>
>
>
>> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >
>> > How about trying to do in main line for now, reserving branch until
>> > needed?
>> >
>> > We'd agree that committers put in the patches and test on supported
>> > platforms (not IPF) and those doing the IPF work test and adjust as
>> > necessary.
>> >
>> > That way, we at least try to keep one codeline that we know works. It
>> > also would "restrict" the freedom of the IPF contributions to stay
>> > within the bounds of the mainline code, and in the event an
>> architecture
>> > change is needed to support IPF that would affect other platforms, we
>> > can talk together.
>> >
>> > I volunteer to help with the IPF patches.
>> >
>> >
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Rana Dasgupta <rd...@gmail.com>.
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebase
they will virtually be a branch. While they are architecturally quite
seperate, they are seperate enough to maybe not cause a lot of conflict.
So the question is really one of how we want to manage this, and if we want
to consider the IPF work as mainline work or secondary. That is my
understanding. I am fine with Geir's choice, and his comment about it being
easier to manage one codeline makes sense. But I would request leaving this
open for some more comments from the jit guys and others before we decide.
Thanks,
Rana
> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > How about trying to do in main line for now, reserving branch until
> > needed?
> >
> > We'd agree that committers put in the patches and test on supported
> > platforms (not IPF) and those doing the IPF work test and adjust as
> > necessary.
> >
> > That way, we at least try to keep one codeline that we know works. It
> > also would "restrict" the freedom of the IPF contributions to stay
> > within the bounds of the mainline code, and in the event an architecture
> > change is needed to support IPF that would affect other platforms, we
> > can talk together.
> >
> > I volunteer to help with the IPF patches.
> >
> >
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mikhail Loenko wrote:
> 2006/10/16, Mikhail Fursov <mi...@gmail.com>:
>> On 10/16/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >
>> >
>> > Isn't it time to define the official set of supported platforms? ;)
>>
>>
>> After reading the neighbour threads about hardware available for
>> commiters
>> and precommit criteria I think that we have no officially supported
>> platforms today (and IMO this is wrong).
>>
>> What is the difference in your vision between official supported and
>> official not supported platforms?
>
> IMHO the difference is we back commit if it breaks officially supported
> platform and not necessarily do if it breaks unsupported one
If pressed, I would assert that we officially* support Windows XP x86
and Linux** x86.
* = I say "officially" with the caveat that we are all volunteers here,
and support for a platform will only remain as long as people are
willing to volunteer to support it.
** = We should define to be a set of popular platforms. I'll start a
new thread so we can put this to bed and get back to work ;)
geir
>
> Thanks,
> Mikhail
>
>>
>>
>> --
>> Mikhail Fursov
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/10/16, Mikhail Fursov <mi...@gmail.com>:
> On 10/16/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> >
> > Isn't it time to define the official set of supported platforms? ;)
>
>
> After reading the neighbour threads about hardware available for commiters
> and precommit criteria I think that we have no officially supported
> platforms today (and IMO this is wrong).
>
> What is the difference in your vision between official supported and
> official not supported platforms?
IMHO the difference is we back commit if it breaks officially supported
platform and not necessarily do if it breaks unsupported one
Thanks,
Mikhail
>
>
> --
> Mikhail Fursov
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/16/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
>
> Isn't it time to define the official set of supported platforms? ;)
After reading the neighbour threads about hardware available for commiters
and precommit criteria I think that we have no officially supported
platforms today (and IMO this is wrong).
What is the difference in your vision between official supported and
official not supported platforms?
--
Mikhail Fursov
Re: [drlvm] IPF functionality
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/10/16, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Mikhail Loenko wrote:
> > 2006/10/16, Tim Ellison <t....@gmail.com>:
> >> Mikhail Loenko wrote:
> >> > When we bring new platforms how will we make sure that a patch for some
> >> > rare platform would not break another one?
> >>
> >> Beyond sniffing the patch to ensure it looks reasonable, the best a
> >> committer can do is to test it on the platforms he or she has available.
> >> After that we rely on the diversity of the community building and
> >> testing the code to catch any problems; i.e. the change doesn't
> >> necessarily end with the commit, it may still have to be backed out.
> >
>
> And the hope is that we'll have the project's CI system running on lots
> of places.
>
> > How will we define which changes should be backed out?
> > Do you mean that we first define list of "supported" platforms
> > and then we will roll back all the changes that reportedly break
> > build on one of that platform?
>
> Yes - I think that we'll eventually get to that state formally, and
> we're there now informally. I suspect that a change to support IPF that
> broke x86 would be backed out w/o a complaint :)
>
> >
> > What would be the procedure to add a new platform to the list of
> > supported ones? (Well I assume it's a vote, but what are the criteria
> > to be used in that vote?)
>
> I think that having "criteria" for use in a vote misses the point -
> because otherwise we'd determine based on the criteria and not need to vote.
So, you mean that criteria is judgement? ;)
Somehow it works...
Thanks,
Mikhail
>
> I think that it will be based on having people interested in working on
> it and size of user population. If we decide that we're going to
> support a platform, it's a lot of work we're taking on....
>
> geir
>
>
> >
> > Thanks,
> > Mikhail
> >
> >>
> >> There is no guarantee of the stability of HEAD, we only get that by
> >> taking a snapshot and everyone testing it with all platforms (c.f. say
> >> Eclipse that does have a centralized build system).
> >>
> >> Regards,
> >> Tim
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/10/16, Tim Ellison <t....@gmail.com>:
> Geir Magnusson Jr. wrote:
> > Mikhail Loenko wrote:
> >> 2006/10/16, Tim Ellison <t....@gmail.com>:
> >>> Mikhail Loenko wrote:
> >>> > When we bring new platforms how will we make sure that a patch for
> >>> some
> >>> > rare platform would not break another one?
> >>>
> >>> Beyond sniffing the patch to ensure it looks reasonable, the best a
> >>> committer can do is to test it on the platforms he or she has available.
> >>> After that we rely on the diversity of the community building and
> >>> testing the code to catch any problems; i.e. the change doesn't
> >>> necessarily end with the commit, it may still have to be backed out.
> >>
> >
> > And the hope is that we'll have the project's CI system running on lots
> > of places.
> >
> >> How will we define which changes should be backed out?
> >> Do you mean that we first define list of "supported" platforms
> >> and then we will roll back all the changes that reportedly break
> >> build on one of that platform?
> >
> > Yes - I think that we'll eventually get to that state formally, and
> > we're there now informally. I suspect that a change to support IPF that
> > broke x86 would be backed out w/o a complaint :)
>
> Yes, and we've seen that working in practice.
>
> >> What would be the procedure to add a new platform to the list of
> >> supported ones? (Well I assume it's a vote, but what are the criteria
> >> to be used in that vote?)
> >
> > I think that having "criteria" for use in a vote misses the point -
> > because otherwise we'd determine based on the criteria and not need to
> > vote.
> >
> > I think that it will be based on having people interested in working on
> > it and size of user population. If we decide that we're going to
> > support a platform, it's a lot of work we're taking on....
>
> Exactly. Even for esoteric platforms if we can make it work we should
> do so -- i.e. it would always be preferable to move forward by fixing
> the code for all platforms than backing out.
>
> This is a problem we don't have at the moment, so I'm not convinced it
> is worth hypothesizing a solution.
Isn't it time to define the official set of supported platforms? ;)
Thanks,
Mikhail
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Mikhail Loenko wrote:
>> 2006/10/16, Tim Ellison <t....@gmail.com>:
>>> Mikhail Loenko wrote:
>>> > When we bring new platforms how will we make sure that a patch for
>>> some
>>> > rare platform would not break another one?
>>>
>>> Beyond sniffing the patch to ensure it looks reasonable, the best a
>>> committer can do is to test it on the platforms he or she has available.
>>> After that we rely on the diversity of the community building and
>>> testing the code to catch any problems; i.e. the change doesn't
>>> necessarily end with the commit, it may still have to be backed out.
>>
>
> And the hope is that we'll have the project's CI system running on lots
> of places.
>
>> How will we define which changes should be backed out?
>> Do you mean that we first define list of "supported" platforms
>> and then we will roll back all the changes that reportedly break
>> build on one of that platform?
>
> Yes - I think that we'll eventually get to that state formally, and
> we're there now informally. I suspect that a change to support IPF that
> broke x86 would be backed out w/o a complaint :)
Yes, and we've seen that working in practice.
>> What would be the procedure to add a new platform to the list of
>> supported ones? (Well I assume it's a vote, but what are the criteria
>> to be used in that vote?)
>
> I think that having "criteria" for use in a vote misses the point -
> because otherwise we'd determine based on the criteria and not need to
> vote.
>
> I think that it will be based on having people interested in working on
> it and size of user population. If we decide that we're going to
> support a platform, it's a lot of work we're taking on....
Exactly. Even for esoteric platforms if we can make it work we should
do so -- i.e. it would always be preferable to move forward by fixing
the code for all platforms than backing out.
This is a problem we don't have at the moment, so I'm not convinced it
is worth hypothesizing a solution.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mikhail Loenko wrote:
> 2006/10/16, Tim Ellison <t....@gmail.com>:
>> Mikhail Loenko wrote:
>> > When we bring new platforms how will we make sure that a patch for some
>> > rare platform would not break another one?
>>
>> Beyond sniffing the patch to ensure it looks reasonable, the best a
>> committer can do is to test it on the platforms he or she has available.
>> After that we rely on the diversity of the community building and
>> testing the code to catch any problems; i.e. the change doesn't
>> necessarily end with the commit, it may still have to be backed out.
>
And the hope is that we'll have the project's CI system running on lots
of places.
> How will we define which changes should be backed out?
> Do you mean that we first define list of "supported" platforms
> and then we will roll back all the changes that reportedly break
> build on one of that platform?
Yes - I think that we'll eventually get to that state formally, and
we're there now informally. I suspect that a change to support IPF that
broke x86 would be backed out w/o a complaint :)
>
> What would be the procedure to add a new platform to the list of
> supported ones? (Well I assume it's a vote, but what are the criteria
> to be used in that vote?)
I think that having "criteria" for use in a vote misses the point -
because otherwise we'd determine based on the criteria and not need to vote.
I think that it will be based on having people interested in working on
it and size of user population. If we decide that we're going to
support a platform, it's a lot of work we're taking on....
geir
>
> Thanks,
> Mikhail
>
>>
>> There is no guarantee of the stability of HEAD, we only get that by
>> taking a snapshot and everyone testing it with all platforms (c.f. say
>> Eclipse that does have a centralized build system).
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/10/16, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > When we bring new platforms how will we make sure that a patch for some
> > rare platform would not break another one?
>
> Beyond sniffing the patch to ensure it looks reasonable, the best a
> committer can do is to test it on the platforms he or she has available.
> After that we rely on the diversity of the community building and
> testing the code to catch any problems; i.e. the change doesn't
> necessarily end with the commit, it may still have to be backed out.
How will we define which changes should be backed out?
Do you mean that we first define list of "supported" platforms
and then we will roll back all the changes that reportedly break
build on one of that platform?
What would be the procedure to add a new platform to the list of
supported ones? (Well I assume it's a vote, but what are the criteria
to be used in that vote?)
Thanks,
Mikhail
>
> There is no guarantee of the stability of HEAD, we only get that by
> taking a snapshot and everyone testing it with all platforms (c.f. say
> Eclipse that does have a centralized build system).
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> When we bring new platforms how will we make sure that a patch for some
> rare platform would not break another one?
Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the platforms he or she has available.
After that we rely on the diversity of the community building and
testing the code to catch any problems; i.e. the change doesn't
necessarily end with the commit, it may still have to be backed out.
There is no guarantee of the stability of HEAD, we only get that by
taking a snapshot and everyone testing it with all platforms (c.f. say
Eclipse that does have a centralized build system).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/16, Mikhail Loenko <ml...@gmail.com>:
> 2006/10/14, Tim Ellison <t....@gmail.com>:
> > Just to add my 2p -- I also agree with doing the work in the trunk. Of
> > course the minimum cost of working there is that you do no harm to the
> > other platforms. That is the zeroth level of integration.
> >
> > The first level of integration would then be to modify the build system
> > to build the IPF code, and of course it has to compile, know it's
> > dependencies, etc. etc.
> >
> > Until the code can run some useful tests it is probably worth going on
> > to run only a restricted set of the tests we have and then take on more.
> >
> > We can be bringing a number of new platforms on line simultaneously this
> > way, with each potentially being at a different level of
> > integration/maturity within the project.
>
> When we bring new platforms how will we make sure that a patch for some
> rare platform would not break another one?
Supposed we can charge CC on all supported platforms:
while (!passed.on.available platforms) {
defer patch & discuss;
}
do commit;
if (some.platform.CC.failed) {
rollback or fix ASAP;
}
>
> Thanks,
> Mikhail
>
> >
> > Regards,
> > Tim
> >
> > Rana Dasgupta wrote:
> > > On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > >
> > >> >
> > >> > > This is just one more argument for doing IPF porting in a separate
> > >> > branch,
> > >> > > at least since some point.
> > >> > >
> > >> > > I admit that maintaining quality and checking for regressions on new
> > >> > > platforms is a separate big problem but I believe we could try to
> > >> > avoid it
> > >> > > during "incubation" of new platforms.
> > >> > >
> > >> > > Overall I agree we could wait with branch creation until real
> > >> problems
> > >> > > appear.
> > >> > >
> > >> >
> > >> > Great
> > >>
> > >>
> > > OK, we can then continue as is until the IPF port matures and is ready for
> > > running non trivial applications or performance tests. At that point we can
> > > decide whether to treat it as a primary platform, in which case, we will
> > > need to test on it before committing submissions to the main branch. Or
> > > secondary, in which case we branch it and let the IPF submitters control
> > > their own destiny.
> > >
> > > Thanks for the good comments.
> > >
> > > Rana
> > >
> > >
> > >
> > >
> > >
> > >> ---------------------------------------------------------------------
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >>
> > >>
> > >
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/10/14, Tim Ellison <t....@gmail.com>:
> Just to add my 2p -- I also agree with doing the work in the trunk. Of
> course the minimum cost of working there is that you do no harm to the
> other platforms. That is the zeroth level of integration.
>
> The first level of integration would then be to modify the build system
> to build the IPF code, and of course it has to compile, know it's
> dependencies, etc. etc.
>
> Until the code can run some useful tests it is probably worth going on
> to run only a restricted set of the tests we have and then take on more.
>
> We can be bringing a number of new platforms on line simultaneously this
> way, with each potentially being at a different level of
> integration/maturity within the project.
When we bring new platforms how will we make sure that a patch for some
rare platform would not break another one?
Thanks,
Mikhail
>
> Regards,
> Tim
>
> Rana Dasgupta wrote:
> > On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> >> >
> >> > > This is just one more argument for doing IPF porting in a separate
> >> > branch,
> >> > > at least since some point.
> >> > >
> >> > > I admit that maintaining quality and checking for regressions on new
> >> > > platforms is a separate big problem but I believe we could try to
> >> > avoid it
> >> > > during "incubation" of new platforms.
> >> > >
> >> > > Overall I agree we could wait with branch creation until real
> >> problems
> >> > > appear.
> >> > >
> >> >
> >> > Great
> >>
> >>
> > OK, we can then continue as is until the IPF port matures and is ready for
> > running non trivial applications or performance tests. At that point we can
> > decide whether to treat it as a primary platform, in which case, we will
> > need to test on it before committing submissions to the main branch. Or
> > secondary, in which case we branch it and let the IPF submitters control
> > their own destiny.
> >
> > Thanks for the good comments.
> >
> > Rana
> >
> >
> >
> >
> >
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Tim Ellison <t....@gmail.com>.
Just to add my 2p -- I also agree with doing the work in the trunk. Of
course the minimum cost of working there is that you do no harm to the
other platforms. That is the zeroth level of integration.
The first level of integration would then be to modify the build system
to build the IPF code, and of course it has to compile, know it's
dependencies, etc. etc.
Until the code can run some useful tests it is probably worth going on
to run only a restricted set of the tests we have and then take on more.
We can be bringing a number of new platforms on line simultaneously this
way, with each potentially being at a different level of
integration/maturity within the project.
Regards,
Tim
Rana Dasgupta wrote:
> On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>> >
>> > > This is just one more argument for doing IPF porting in a separate
>> > branch,
>> > > at least since some point.
>> > >
>> > > I admit that maintaining quality and checking for regressions on new
>> > > platforms is a separate big problem but I believe we could try to
>> > avoid it
>> > > during "incubation" of new platforms.
>> > >
>> > > Overall I agree we could wait with branch creation until real
>> problems
>> > > appear.
>> > >
>> >
>> > Great
>>
>>
> OK, we can then continue as is until the IPF port matures and is ready for
> running non trivial applications or performance tests. At that point we can
> decide whether to treat it as a primary platform, in which case, we will
> need to test on it before committing submissions to the main branch. Or
> secondary, in which case we branch it and let the IPF submitters control
> their own destiny.
>
> Thanks for the good comments.
>
> Rana
>
>
>
>
>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Rana Dasgupta <rd...@gmail.com>.
On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > > This is just one more argument for doing IPF porting in a separate
> > branch,
> > > at least since some point.
> > >
> > > I admit that maintaining quality and checking for regressions on new
> > > platforms is a separate big problem but I believe we could try to
> > avoid it
> > > during "incubation" of new platforms.
> > >
> > > Overall I agree we could wait with branch creation until real problems
> > > appear.
> > >
> >
> > Great
>
>
OK, we can then continue as is until the IPF port matures and is ready for
running non trivial applications or performance tests. At that point we can
decide whether to treat it as a primary platform, in which case, we will
need to test on it before committing submissions to the main branch. Or
secondary, in which case we branch it and let the IPF submitters control
their own destiny.
Thanks for the good comments.
Rana
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Slava Shakin wrote:
> Geir,
>
> The following scenario illustrates my point (just in case):
> Let's assume that IPF porting group managed to run "hello world" on IPF in
> the main trunk. The next goal might be a bit more sophisticated workload
> (like Eclipse). For fast progress towards that goal the IPF porting group
> will not want any regressions wrt their results in the branch they work
> with. But patches from other (non-IPF) contributors are not supposed to be
> tested on IPF and can easily break even building on that platform.
Agreed.
>
> This is just one more argument for doing IPF porting in a separate branch,
> at least since some point.
>
> I admit that maintaining quality and checking for regressions on new
> platforms is a separate big problem but I believe we could try to avoid it
> during "incubation" of new platforms.
>
> Overall I agree we could wait with branch creation until real problems
> appear.
>
Great
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Sergey Soldatov <se...@gmail.com>.
If something can break IPF build it will break it during the merge. And in
this case it will take much more efforts and time to find the reason why the
build is broken. IMHO the main reason to make a separate branch is an
absolutely new implementation which will replace an existing one and this is
not our case.
On 10/13/06, Slava Shakin <vy...@gmail.com> wrote:
>
> Geir,
>
> The following scenario illustrates my point (just in case):
> Let's assume that IPF porting group managed to run "hello world" on IPF in
> the main trunk. The next goal might be a bit more sophisticated workload
> (like Eclipse). For fast progress towards that goal the IPF porting group
> will not want any regressions wrt their results in the branch they work
> with. But patches from other (non-IPF) contributors are not supposed to be
> tested on IPF and can easily break even building on that platform.
>
> This is just one more argument for doing IPF porting in a separate branch,
> at least since some point.
>
> I admit that maintaining quality and checking for regressions on new
> platforms is a separate big problem but I believe we could try to avoid it
> during "incubation" of new platforms.
>
> Overall I agree we could wait with branch creation until real problems
> appear.
>
> --
> Slava Shakin, Intel Middleware Products Division
>
> "Geir Magnusson Jr." <ge...@pobox.com> wrote in message
> news:452F56B2.6030802@pobox.com...
> >
> >
> > Slava Shakin wrote:
> >> Hi,
> >>
> >> I have an opposite concern: will the main trunk guarantee it always
> >> builds and works on IPF.
> >
> > Clearly not. It doesn't now.
> >
> >> IMO this will soon become critical for the IPF porting effort but will
> >> imply passing certain pre-commit tests on IPF for any changes which
> >> potentially affect working on this platform. Which relates to another
> >> discussion about the list platforms to test each commit on.
> >
> > Sure - but the model now is that some small group of contributors will
> be
> > working on IPF support, seemingly independently of the rest. I'd think
> > they could ensure that what is offered as patches at least compiles :)
> >
> >>
> >> The first stage of IPF porting effort will probably be porting
> classlibs
> >> and running things in VM interpreter mode. Perhaps, it makes sense to
> >> keep everything in the main trunk during this period. But later we will
> >> likely want a separate branch.
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Sergey Soldatov
Intel Middleware Products Division
Re: [drlvm] IPF functionality
Posted by Slava Shakin <vy...@gmail.com>.
Geir,
The following scenario illustrates my point (just in case):
Let's assume that IPF porting group managed to run "hello world" on IPF in
the main trunk. The next goal might be a bit more sophisticated workload
(like Eclipse). For fast progress towards that goal the IPF porting group
will not want any regressions wrt their results in the branch they work
with. But patches from other (non-IPF) contributors are not supposed to be
tested on IPF and can easily break even building on that platform.
This is just one more argument for doing IPF porting in a separate branch,
at least since some point.
I admit that maintaining quality and checking for regressions on new
platforms is a separate big problem but I believe we could try to avoid it
during "incubation" of new platforms.
Overall I agree we could wait with branch creation until real problems
appear.
--
Slava Shakin, Intel Middleware Products Division
"Geir Magnusson Jr." <ge...@pobox.com> wrote in message
news:452F56B2.6030802@pobox.com...
>
>
> Slava Shakin wrote:
>> Hi,
>>
>> I have an opposite concern: will the main trunk guarantee it always
>> builds and works on IPF.
>
> Clearly not. It doesn't now.
>
>> IMO this will soon become critical for the IPF porting effort but will
>> imply passing certain pre-commit tests on IPF for any changes which
>> potentially affect working on this platform. Which relates to another
>> discussion about the list platforms to test each commit on.
>
> Sure - but the model now is that some small group of contributors will be
> working on IPF support, seemingly independently of the rest. I'd think
> they could ensure that what is offered as patches at least compiles :)
>
>>
>> The first stage of IPF porting effort will probably be porting classlibs
>> and running things in VM interpreter mode. Perhaps, it makes sense to
>> keep everything in the main trunk during this period. But later we will
>> likely want a separate branch.
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Slava Shakin wrote:
> Hi,
>
> I have an opposite concern: will the main trunk guarantee it always builds
> and works on IPF.
Clearly not. It doesn't now.
> IMO this will soon become critical for the IPF porting effort but will imply
> passing certain pre-commit tests on IPF for any changes which potentially
> affect working on this platform. Which relates to another discussion about
> the list platforms to test each commit on.
Sure - but the model now is that some small group of contributors will
be working on IPF support, seemingly independently of the rest. I'd
think they could ensure that what is offered as patches at least compiles :)
>
> The first stage of IPF porting effort will probably be porting classlibs and
> running things in VM interpreter mode. Perhaps, it makes sense to keep
> everything in the main trunk during this period. But later we will likely
> want a separate branch.
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Slava Shakin <vy...@gmail.com>.
Hi,
I have an opposite concern: will the main trunk guarantee it always builds
and works on IPF.
IMO this will soon become critical for the IPF porting effort but will imply
passing certain pre-commit tests on IPF for any changes which potentially
affect working on this platform. Which relates to another discussion about
the list platforms to test each commit on.
The first stage of IPF porting effort will probably be porting classlibs and
running things in VM interpreter mode. Perhaps, it makes sense to keep
everything in the main trunk during this period. But later we will likely
want a separate branch.
--
Slava Shakin, Intel Middleware Products Division
"Mikhail Fursov" <mi...@gmail.com> wrote in message
news:bc79dd600610130026r1b588d1ev4d93a1b47fde7b85@mail.gmail.com...
> On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>> It's harmless now...given it's not interfering with the other stuff,
>> what's the problem?
>
>
> Geir,
> your proposal "to solve a problem only when you feel that it is a
> problem"
> sounds reasonable.
> Right now IPF code is harmless and we can try to start with the trunk.
> Once
> we feel that IPF code needs more freedom or our commiters are too
> overloaded
> to check IPF patches on IA32 we can create a branch for IPF. I'm OK with
> it.
>
> I proposed to use separate branch initially only because I know how it
> works. Do-everything-in-the-trunk is a new technique to me :)
>
>
> --
> Mikhail Fursov
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> It's harmless now...given it's not interfering with the other stuff,
> what's the problem?
Geir,
your proposal "to solve a problem only when you feel that it is a problem"
sounds reasonable.
Right now IPF code is harmless and we can try to start with the trunk. Once
we feel that IPF code needs more freedom or our commiters are too overloaded
to check IPF patches on IA32 we can create a branch for IPF. I'm OK with it.
I proposed to use separate branch initially only because I know how it
works. Do-everything-in-the-trunk is a new technique to me :)
--
Mikhail Fursov
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mikhail Fursov wrote:
> The current state of the IPF code in our codebase is "it won't build". So
> there are a lot of things to do before running first test.
> And for -every- commit of the IPF code IPF developers plus every commiter
> have to check that their changes do not break IA32/EM64T build.
> If you even could not built and run a simple Hello World why to keep it in
> the main trunk?
Because I'm terrified that it's going to be really painful to merge the
branches. I mean, the code won't even build now...
So for every commit of the IPF code, yes, I'm going to check the what I
can in IA32/64T....
>
> So it could be the question of a policy for any new platform we want
> support.
> My proposal is to keep it in a separate branch before it can be built
> and is
> not able to run simple tests.
It's harmless now...given it's not interfering with the other stuff,
what's the problem?
>
> + Do we have any plans about IPF? I mean "run this application before this
> date"?
>
>
>
> On 10/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Friday 13 October 2006 01:37 Geir Magnusson Jr. wrote:
>> > How about trying to do in main line for now, reserving branch until
>> needed?
>> >
>> > We'd agree that committers put in the patches and test on supported
>> > platforms (not IPF) and those doing the IPF work test and adjust as
>> > necessary.
>> >
>> > That way, we at least try to keep one codeline that we know works. It
>> > also would "restrict" the freedom of the IPF contributions to stay
>> > within the bounds of the mainline code, and in the event an
>> architecture
>> > change is needed to support IPF that would affect other platforms, we
>> > can talk together.
>> >
>> > I volunteer to help with the IPF patches.
>>
>> +1
>> I agree with Geir's point of view. Let's resolve the problems in the
>> order
>> they appear. So far there were no huge changes to the code for IPF
>> platform
>> to create a separate branch. Once something like this appears we may
>> return
>> to this discussion.
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Fursov <mi...@gmail.com>.
The current state of the IPF code in our codebase is "it won't build". So
there are a lot of things to do before running first test.
And for -every- commit of the IPF code IPF developers plus every commiter
have to check that their changes do not break IA32/EM64T build.
If you even could not built and run a simple Hello World why to keep it in
the main trunk?
So it could be the question of a policy for any new platform we want
support.
My proposal is to keep it in a separate branch before it can be built and is
not able to run simple tests.
+ Do we have any plans about IPF? I mean "run this application before this
date"?
On 10/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Friday 13 October 2006 01:37 Geir Magnusson Jr. wrote:
> > How about trying to do in main line for now, reserving branch until
> needed?
> >
> > We'd agree that committers put in the patches and test on supported
> > platforms (not IPF) and those doing the IPF work test and adjust as
> > necessary.
> >
> > That way, we at least try to keep one codeline that we know works. It
> > also would "restrict" the freedom of the IPF contributions to stay
> > within the bounds of the mainline code, and in the event an architecture
> > change is needed to support IPF that would affect other platforms, we
> > can talk together.
> >
> > I volunteer to help with the IPF patches.
>
> +1
> I agree with Geir's point of view. Let's resolve the problems in the order
> they appear. So far there were no huge changes to the code for IPF
> platform
> to create a separate branch. Once something like this appears we may
> return
> to this discussion.
>
>
--
Mikhail Fursov
Re: [drlvm] IPF functionality
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 13 October 2006 01:37 Geir Magnusson Jr. wrote:
> How about trying to do in main line for now, reserving branch until needed?
>
> We'd agree that committers put in the patches and test on supported
> platforms (not IPF) and those doing the IPF work test and adjust as
> necessary.
>
> That way, we at least try to keep one codeline that we know works. It
> also would "restrict" the freedom of the IPF contributions to stay
> within the bounds of the mainline code, and in the event an architecture
> change is needed to support IPF that would affect other platforms, we
> can talk together.
>
> I volunteer to help with the IPF patches.
+1
I agree with Geir's point of view. Let's resolve the problems in the order
they appear. So far there were no huge changes to the code for IPF platform
to create a separate branch. Once something like this appears we may return
to this discussion.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
How about trying to do in main line for now, reserving branch until needed?
We'd agree that committers put in the patches and test on supported
platforms (not IPF) and those doing the IPF work test and adjust as
necessary.
That way, we at least try to keep one codeline that we know works. It
also would "restrict" the freedom of the IPF contributions to stay
within the bounds of the mainline code, and in the event an architecture
change is needed to support IPF that would affect other platforms, we
can talk together.
I volunteer to help with the IPF patches.
Mikhail Fursov wrote:
> Rana,
> I support the first item: to have a separate branch for IPF with periodical
> merges to the trunk. Do tests only on merge.
> IMO it will simplify the startup for IPF contributors.
> Once IPF is ready to run apps as our IA32 version does it will be the time
> to move IPF into the trunk.
>
> + Are there any volunteers to support IPF? Once somebody is interested I
> will be glad to help with JIT issues.
>
> On 10/13/06, Rana Dasgupta <rd...@gmail.com> wrote:
>>
>> Hi,
>> There is incomplete support for IPF platforms in the DRLVM codebase, as
>> many may have seen. It would be nice to complete it. There are a
>> couple of
>> issues on how to start this. IPF specific changes are likely to be quite
>> significant, including changes in the JIT, garbage collector(s),
>> exception
>> handling model and other core VM areas, as well as IPF functionality and
>> performance specific tests. Given the invasive nature of these
>> changes, it
>> seems to me that we could:
>>
>> 1. Create a seperate branch in svn and do all IPF work there. JIRA
>> submissions could be clearly marked [IPF]. Since most committers may not
>> have access to IPF paltforms ( a safe guess :-) ) right now, they could
>> help
>> by just applying the patches and committing the IPF submissions into the
>> branch( without testing, but certainly code review comments and IPF
>> verification, if possible are welcome ). It would be the responsibility
>> of
>> the few IPF code contributors to keep their branch tested and stable.
>> This
>> means some additional work for the committers, but worse..at some point
>> when
>> the IPF port is completed, if we want to merge the code back into the
>> trunk,
>> that will not be a small task.
>> 2. Not create a seperate branch. Committers ( at least those without
>> access
>> to IPF ) could verify on their favorite IA32 or EM64T platform before
>> committing the IPF related changes also into trunk. This way, we are not
>> defering the merge problem, but overall everyone is impacted because
>> there
>> will be more commits into the trunk, more conflicts, and things will be
>> somewhat slower. This is somewhat the model that we are following with
>> EM64T specific submissions now, but IPF specific changes and submissions
>> are
>> expected to be of higher volume.
>> 3. Follow 1, but always keep IPF as a special platform on a seperate
>> branch. Never merge back. As IPF functionality is more complete and
>> committers get access to IPF machines, we just start testing more
>> rigorously before commiting IPF code and also start running automated
>> tests
>> ( whatever we are doing in the main branch ). IPF distributions can be
>> rolled out of its own branch.
>>
>> However we do it could be a model for porting to other future platforms (
>> let's say Mac ) as well. Comments or other ideas?
>>
>> Thanks,
>> Rana
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] IPF functionality
Posted by Mikhail Fursov <mi...@gmail.com>.
Rana,
I support the first item: to have a separate branch for IPF with periodical
merges to the trunk. Do tests only on merge.
IMO it will simplify the startup for IPF contributors.
Once IPF is ready to run apps as our IA32 version does it will be the time
to move IPF into the trunk.
+ Are there any volunteers to support IPF? Once somebody is interested I
will be glad to help with JIT issues.
On 10/13/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
> Hi,
> There is incomplete support for IPF platforms in the DRLVM codebase, as
> many may have seen. It would be nice to complete it. There are a couple of
> issues on how to start this. IPF specific changes are likely to be quite
> significant, including changes in the JIT, garbage collector(s), exception
> handling model and other core VM areas, as well as IPF functionality and
> performance specific tests. Given the invasive nature of these changes, it
> seems to me that we could:
>
> 1. Create a seperate branch in svn and do all IPF work there. JIRA
> submissions could be clearly marked [IPF]. Since most committers may not
> have access to IPF paltforms ( a safe guess :-) ) right now, they could
> help
> by just applying the patches and committing the IPF submissions into the
> branch( without testing, but certainly code review comments and IPF
> verification, if possible are welcome ). It would be the responsibility
> of
> the few IPF code contributors to keep their branch tested and stable. This
> means some additional work for the committers, but worse..at some point
> when
> the IPF port is completed, if we want to merge the code back into the
> trunk,
> that will not be a small task.
> 2. Not create a seperate branch. Committers ( at least those without
> access
> to IPF ) could verify on their favorite IA32 or EM64T platform before
> committing the IPF related changes also into trunk. This way, we are not
> defering the merge problem, but overall everyone is impacted because there
> will be more commits into the trunk, more conflicts, and things will be
> somewhat slower. This is somewhat the model that we are following with
> EM64T specific submissions now, but IPF specific changes and submissions
> are
> expected to be of higher volume.
> 3. Follow 1, but always keep IPF as a special platform on a seperate
> branch. Never merge back. As IPF functionality is more complete and
> committers get access to IPF machines, we just start testing more
> rigorously before commiting IPF code and also start running automated
> tests
> ( whatever we are doing in the main branch ). IPF distributions can be
> rolled out of its own branch.
>
> However we do it could be a model for porting to other future platforms (
> let's say Mac ) as well. Comments or other ideas?
>
> Thanks,
> Rana
>
>
--
Mikhail Fursov