harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] IPF functionality
Date Thu, 12 Oct 2006 21:37:38 GMT
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 

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 <rdasgupt@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

View raw message