harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject [drlvm] IPF functionality
Date Thu, 12 Oct 2006 19:55:28 GMT
  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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message