Where/how should we build for ARM?

[JamesKingdon]

With the merge of ibmruntimes/openj9-openjdk-jdk9#88 it should now be possible to build for armhf, possibly with something similar to the yml that I use for travis.ci on my fork:

https://github.com/JamesKingdon/openj9-openjdk-jdk9/blob/arm/.travis.yml

What's the right way of doing this within OpenJ9, or would this be better done under AdoptOpenJDK?

If possible I'd like to get arm building and running tests regularly so that we can keep an eye out for regressions.

[pshipton]

To do it at OpenJ9, the project first needs (a) machines for cross compiling (b) machines for testing. I don't think either of these are available atm. There aren't yet any xLinux machines available to OpenJ9, although they are a work in progress.

[AdamBrousseau]

Technically we have x via TravisCI, which has the option to upload artifacts to Amazon S3. We could use that process to cross-compile but I assume we'd have to pay for the storage and it would be pretty hacky.

I assume we can only cross-compile on xLinux?

[JamesKingdon]

xLinux is the only host I've tested on, although I guess in principle we could use anything that the toolchain is available for. What would be most convenient host from an availability point of view, pLinux?

[AdamBrousseau]

p/z, we have 4 of each. I think we usually have higher utilization on p since they seem to be faster.

[jabrena]

Hi @JamesKingdon, with current status of the project, is not possible to cross compile for ARM Soft Float?

[JamesKingdon]

Hi @jabrena I haven't tried building for soft float yet, but I'm hopeful that it won't be too difficult to do. I have a set of changes that allow us to select between building for ARMv6 or ARMv7 that weren't too difficult, so adding the soft vs hard float will likely be similar. The biggest problem is making sure that the flags make it to all the parts of the project.

@AdamBrousseau I'll have a search and see if I can find the toolchain for either p or z.

[JamesKingdon]

I didn't find a p/z hosted tool chain. We could look at building one from source, but I'm reluctant to head down that route. We could go with travis-ci for build, it takes about half an hour so it's not out of the question, but that would still leave us with a question mark for testing the executable. I suspect it's best to leave this on ice for now and revisit when we have the necessary hardware.

[mateli]

I'm ready to set up a cluster based on Raspberry Pi 3 for doing this. I don't know what software should be used to build and run tests but a Pi cluster doesn't take an enormous amount of space and I can use it for other stuff.

[pshipton]

@mateli afaik nobody is pursuing getting ARM 32-bit to work any more. There is ongoing work to get AArch64 working. I believe it is running in interpreter only mode atm, enabling the JIT is WIP. You can search issues and PRs for aarch64 to see the ongoing work.

A couple of interesting ones are
#4696
#4854

[mateli]

@pshipton Rpi 3 should be able to build for AArch64 as well if that is needed. Well WIP is better than nothing which is the progress on Hotspot.

[pshipton]

Hotspot has AArch64 support
https://adoptopenjdk.net/releases.html?variant=openjdk8&jvmVariant=hotspot#aarch64_linux

[mateli]

Using Hotspot Zero and not they JIT as far as I know.
https://git.linaro.org/arm/vixl.git
I found these which seems to be what Chrome/Chromium uses for JavaScript JIT:ing and perhaps also for Androids JVM. That is the only JIT I found for ARM.
It supports A64, A32 and T32 code generation so it would really cover all bases.

[mateli]

Hotspot has AArch64 support
Raspberry Pi Zero hasn't.

[rhaley-starfish]

Bummer. We have a wandboard (NXP iMX6 armv7) based system that could really use this.

[SathishGunasekaran]

I need to build openj9 jdk with ARMv7. Please add the instructions to build.

[0xdaryl]

Unfortunately, ARMv7 is on a path to deprecation/removal in OpenJ9 (see details in #10412) so there aren't any current instructions for building. While some of the code still exists in the code base, the plan is to remove it eventually. Lack of demand from the community, lack of infrastructure resources to build and test ARMv7, and overall staleness of the ARMv7 port are the main reasons.

If there are significant use cases for ARMv7 I would appreciate comments in #10412, but unfortunately that won't be a guarantee that the code will be pardoned and supported someday.

I will close this issue now.