Re: [rvm-core] Next steps for x64 support?

[Erik B. <eri...@gm...>]

Hi,

On 04.11.2013 00:35, Steve Blackburn wrote:
> I am happy to provide a dedicated x64 testing machine if we think that would be useful (which I suspect is true).   At the same time I'd like to shake the cobwebs off some of the other testing machines here at ANU.

A dedicated x64 machine would be very useful once the x64 builds can run larger programs. I don't know how long it will take to get to this point. I suppose there's no need to hurry.

> [...] try to break the future work down from a single monolithic task into some more manageable chunks, [...]

I've tried to do this both for x64 (e.g. RVM-986) and OpenJDK (e.g. RVM-1045) in the past. The act of splitting the patch up is already a large part of work because the patch set is not clean.

For example, the changes in the x64 change set are not always sensibly assigned to the patches (e.g. changes to files from opt-ir in the baseline patch). Some x64 changes in the patch set are pulled from MRP but are missing parts (this was the case for the libvm.c 64-bit fixes). There are changes that were left over from other work (see e.g. probably-unneeded-changes.patch in RVM-986).

To reduce the patch set for x64 by one "commit", we have to:
a) Determine if there's a MRP commit that contains the changes. We need to do this so that we can check if a commit was pulled completely (i.e. we're not missing any fixes) and if there are subsequent bugfixes for that commit. This step also requires close inspection of the commit to determine what we need to pull (e.g. in case of commits that mix several changes or that contain merges with Jikes RVM code).
b) If it's not a MRP commit, search the bugtrackers and mailing lists of the Jikes RVM and MRP project to see if there's any information by Da Feng that helps in determining what belongs to the conceptual commit.
c) Determine if we need to (or should) add tests for the fixes/changes.
d) Prepare the commit.

> (FWIW, I think it would be good to do the same for the OpenJDK port --- break it down into more manageable work units)

The problems for OpenJDK are similar to those for x64. And there's few references for commits that can be used. This makes it harder to merge than x64 (at least for me).

I personally will continue to work only on one large item (e.g. x64, OpenJDK, rdb, ...) at a time. I'll stick with x64 for the time being. I won't reconsider this until one of the other items is available in a form that's easier to merge (e.g. grouped into commits as opposed to diffs).

> and post them as separable JIRA items.

Working via JIRA is complicated by the current lack of an easy way to register on JIRA for new users (see http://jira.codehaus.org/browse/HAUS-2299 ). It is still possible to register via Xircles and this is mentioned on our reporting bugs page but it's not a nice situation.

> ideally [...] being accessible to other eager contributors, 

The best way for potential contributors to start helping with OpenJDK are the changes to sun.misc.Unsafe (and potentially org.jikesrvm.runtime.Memory), i.e. RVM-1045.


Kind regards,

Erik Brangs