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 <[EMAIL PROTECTED]> 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