ARM build? #53
Labels
Comments
|
We build an ARM VM from the OpenJ9 code base for Java 8. I haven't heard a build has been tried for Java 9, but it should work. The VM works with -Xint (interpreted only - no JIT) but isn't yet supported by the JIT. You are welcome to try building it, I expect most or all of the changes required to build it are in the build files found in https://github.com/ibmruntimes/openj9-openjdk-jdk9 i.e. setting the OPENJ9_CPU, OPENJ9_PLATFORM_CODE, OPENJ9_BUILDSPEC (to /buildspecs/linux_arm.spec) in /openj9-openjdk-jdk9/closed/autoconf/custom-hook.m4 @jdekonin fyi |
|
To add some context to the above, we've had JIT working on ARM in previous releases of the JVM, but during the release of OpenJ9 we haven't been able to prioritise this platform. At this point OpenJ9 on ARM is mostly untested so some bugs are to be expected, and we also know that there are opportunities for improving the performance. We hope to work through these issues as resources permit, and we certainly welcome any help along the way! |
|
so I don't seem to be terribly successful yet. I have very limited JVM knowledge so maybe the following will sound familiar to people? |
|
Try swapping note "JIT disabled" on the second one above. |
|
Right, my apologies. I didn't realize that this time around I had mixed up the args. I had already realized that it didn't work even with JIT properly disabled (didn't pay attention this time) it still fails. See below, without JIT this time, and thanks for the super fast response! 😄 Note: I've switched to a zero variant as I thought this might minimize the lower the chances of running into incompatible assembly code issues but certainly had a similar issue with a "client" build. |
|
BTW isn't 'zero' supposed to be interpreted-only anyways? |
|
More than that, I believe it is supposed to be free of any assembler code. As far as I know we haven't attempted to support zero yet. |
|
@JamesKingdon I am compiling native, I thought it would be simpler (albeit much much slower of course :-)). And my main computer is a Mac anyways and cross compilation of openJDK from MacOS to ARM seems to have many glitches anyways (or I am just doing it wrong :)) |
|
I am quoting a bit of openjdk-jdk9 common/doc/building.md here, "..A number of pre-defined ABI profiles are available using I believe you will be able to find these options in the ~/Repositories/openj9-openjdk-jdk9/build/linux-arm-normal-zero-release/spec.gmk file at is generated in the configure stage. It would be good to review any other compiler option detailed in the spec.gmk for compatibility with the toolchain you are using. There is also a specific toolchain openjdk suggests to use within a cross-compile environment. So this might be a challenge for openjdk-jdk9 without openj9. It might be worth testing openjdk9 on its own within the same environment. |
|
@jdekonin Thanks for the hint. Looks like it is actually recommended to cross-compile rather than try and go native, so I guess I will try that. I am not sure what you mean when you say that the specific toolchain they recommend will be a challenge for openjdk-jdk9 without openj9? FWIW I was building with ABI profile 'arm-vfp-hflt' |
|
@kartben, I was just meaning that maybe you should try openjdk on its own as a starting point. The failure you are seeing appears to be in libjava.so which isn't something that is being modified afaik. |
|
To put it another way: the problem is an Illegal instruction, meaning the options used to compile the code don't match the hardware used to run. The code causing the Illegal instruction is part of OpenJDK (libjava.so), and not OpenJ9. It seems the OpenJDK part of the build needs to change to use a different profile. OpenJ9 is setup to compile ARM for hard float (hflt) and OpenJDK should be built the same way. |
|
Thanks @pshipton. That helps. |
|
It is wrong, but I don't find any references to aotTarget or aot_target in the OpenJ9 code. I suspect its obsolete and not used any more. These buildspecs contain obsolete information and settings only useful to IBM internal builds. There is an effort underway to change the builds to use cmake, I expect all the buildspecs will be cleaned up when this conversion occurs. |
|
Makes sense. I couldn't find any reference to aotTarget in the codebase either but thought I would ask :-) |
|
Cross-compilation of an OpenJDK JVM is a success, let's see what happens if I replicate the compilation settings for openj9… And I also need to get a working version of qemu-arm to be able to run 'constgen' and 'j9ddrgen' (unfortunately I use MacPorts instead of Homebrew and qemu-arm does not seem to be part of the ports package for qemu. |
|
Just FYI, OpenJ9 doesn't use j9ddrgen. This is turned off as the tools used to build it are not available in the open. Its going to be obsoleted once the dwarf replacement happening in omr is ready. |
|
qemu-arm is just an emulator openj9 uses to run constgen because hardcoded as a cross-compile platform. If you open and modify openj9/runtimes/jilgen/module.xml and just run 'constgen' directly that should work. You should see at the bottom of the file... remove this section.... I don't have access to a pi atm, otherwise I would verify this works. Thanks for the work you have been putting into getting this going though!! Update: I was thinking that you were compiling directly on the pi, not cross compiling when I made this comment. If you are going to continue with the cross compile try qemu.org and don't make the modification to above. |
|
@kartben, in case you are just reading the email updates and its confusing, I edited the last comment a few times read it issue itself :) |
|
@jdekonin I am going down the cross compile path now so yeah I do need qemu to run constgen (unless it's a "self-contained" exec and maybe in that case i can run it directly like you suggest by pointing my module.xml at a constgen that I would build for the mac?). |
|
@jdekonin and yes of course your suggested change to openj9/runtimes/jilgen/module.xml works just fine, and this is what i was doing when compiling directly on the Pi 😄 BTW I guess the should be improved so that to not try to use qemu if we are already building on an arm machine? |
|
Hello everyone! has anyone succeeded in building for armhf? I am getting this error when trying to cross-compile from a Linux x64 environment: Also, here is the config summary: |
|
@AlexBudesteanu, a bit of review and I believe I understand what is happening here. Cross-compiling with openj9 currently generates binaries only for the target images. Technically its attempting to use the target generated binaries on x86 which is the file format error. Cross-compiling openjdk binaries are generated for the build-jdk (host system) and then for the target images (jdk/jre). Its the generating of the binaries for the build-jdk that isn't incorporated in the openj9 work. I believe if you re-run configure with --with-build-jdk (path to JDK of same version as is being built), this should workaround that issue. It will also mean a faster compile as it won't be generating an xLinux buildjvm as well. That the build-jdk will need to be at JDK-9+181 tag or later. You can grab a pre-built one from https://adoptopenjdk.net/?variant=openjdk9-openj9. The build-jdk is used to build the v9 jmods and module, so you cannot use the boot-jdk of java8. Search cross-compile for more information |
|
I gave this another go and ran into a few problems... I did eventually get a successful compile, but it segfaults very early in VM startup with what looks like a recursive function pointer error. |
|
Any progress with this issue? |
|
I tracked down the problem with thumb code - the native methods in the jdk tree were being compiled for thumb. The problem was caused by passing the wrong abi profile to the configure script. I had been using arm-vfp-hflt which results in -march=armv7-a -mthumb being passed to the compiler. Changing the abi profile to xarmv6-vfp-hflt gives -march=armv6 -marm, which should be compatible with the way that the rest of OpenJ9 is being built. (see flags.m4 in common/autoconf). Debugging this was a lot easier once I could see the compilation commands by using LOG=cmdlines on the make invocation. |
|
OK, good news - I managed to manually get a build going, complete with JIT: The bad news is that the JIT is quite unstable when running anything other than trivial programs. I'll try and work through the issues I raised to get regular builds enabled, and then I'll focus on the JIT stability issues. Realistically, we have quite a lot of work still ahead of us. |
|
Congrats!!! |
|
I can get some non-trivial programs running by using the following options: The gcpolicy option is to work around missing implementation in the ARM codegen for the array copy evaluator. I've opened an OMR issue to track that problem: I haven't looked at the JNI direct call problem yet, but the fact the it only takes the two options to get some bigger programs running suggests the code isn't too badly broken after all :) |
|
Sorry for the slow progress. I'm working my way through the changes to the build and submitting PRs for each. I've also created a docker file that brings together the cross compiler tool chain and the required native libraries. |
|
Time for another status update. The good news is that we're getting closer. I've submitted the following pull requests that together permit cross compilation from an x86 hosted Docker container: #622 Changes have been requested by the reviewers, so it will take some time to work through those before we finally have working ARM builds in the main code base. The less good news is that the resulting JVM has functional and performance issues that we need to track down. In some cases there are workarounds that can be applied at the command-line, some of the newer problems we haven't characterized well enough to find a work-around yet. I wouldn't recommend trying the ARM build for anything other than curiosity or test & development of the JVM at this stage, but if you do want to get an early look, you can get a completely unofficial version by pulling from my personal forks and following the instructions at https://github.com/JamesKingdon/openj9/blob/arm-build-instructions/buildenv/Build_Instructions_V9.md#arm |
|
Hi @JamesKingdon, I will try this weekend. Juan Antonio |
|
I've made another set of changes to the ARM build in response to the PR reviews and updated the instructions to match. I think the only external difference is for building the x86 build JDK locally (the very last and entirely optional section of the instructions), so hopefully it doesn't impact anyone. But if you had started building yesterday and come back to the online instructions today you might find some discrepancies. |
|
As a result of making all the branches have the same name ('arm') the instructions moved to |
|
The build instructions work, I've gotten a build working on a Pandaboard. A few minor missing details about the build instructions: The rest was straightforward. Great stuff. |
|
Hey @kaiwalyajoshi , that's great news - many thanks for trying it out. In the instructions I go for unpacking the build JDK outside of the docker image and then mounting it as a volume.
I can see it would look more natural to have the build JDK handled inside the docker image like other dependencies. The current state of play stems from a combination of a separate build JDK being a temporary fix until we can get it automatically created during the normal build process, and the fact that there isn't a 'latest-nightly' link that I could easily use to automate the installation. Weak arguments I know - I'll take another look at the setup and see if I can smooth this out. Edit: Ah, but the comment in the Dockerfile doesn't mention the volume for the build jdk. I need to make things consistent, one way or another! Thanks again for the feedback. |
|
Two out of three projects merged the changes, but ibmruntimes/openj9-openjdk-jdk9#88 is taking longer than expected. |
|
I've updated the build-docker-arm script (and .travis.yml) to use the official repos for OpenJ9 and omr-openJ9. This has the advantage of getting the latest changes for those repos, and the disadvantage of not having some of my recent fixes for arm, so you need to use disableDirectToJNI, and it's built for armv6 instead of armv7. Travis.ci is setup to put the binaries in the releases section of my openj9-openjdk-jdk9, so you can pick up either a jdk or jre from https://github.com/JamesKingdon/openj9-openjdk-jdk9/releases/tag/20171217193531-f232f3a6 |
|
Hi @JamesKingdon, |
|
Hi @JakubVanek, agreed, I think there's some clean-up needed in those files. Possibly they will get revamped as part of the move to CMake. Thanks for pointing it out. |
|
Hi guys, Thanks to all people involved for this great project! Would be really really great if we could use openJ9 for ARM. I had only great experiences with J9 for embedded Java in a Telematics project. BR Mehmet |
|
Hi @marziman thanks for your post and encouragement :) We need to get the build into our regular build & test cycle to shake out any remaining bugs. The known functional issues have been identified and addressed by @knn-k and are either in the code base or on their way. Which leaves us with performance - definitely not where we want it to be yet, so we need to characterise the problems and prioritise improvements. Further out, we obviously are aware of the need for a 64bit implementation and exploitation of more hardware features. |
|
Great thanks @JamesKingdon ! Would be great. |
|
Hi @marziman |
|
Sorry for the long delay, I'm finding it increasingly hard to get time to work on this. The port is basically working, although there remain a number of failures in the test suites that need to be tracked down (not all of them are necessarily ARM specific, so identifying the subset that are will need to be part of the work). The main step that needs to be taken to unblock more progress is to move from my unofficial builds on travis-ci to integrating with the project build systems. There is #1159 to track this. |
dhong44
pushed a commit
to dhong44/openj9
that referenced
this issue
May 31, 2018
…9-revert-48-ibm_sdk Revert "Enable atomic-free JNI on select platforms"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm interested in trying out OpenJ9 on e.g Raspberry Pi. It doesn't look like armv7l is supported out-of-the-box although the codebase certainly has some references to ARM arch.
What's the timeline for getting ARM support and/or can I already try and hack something together? If the latter, some initial pointers would be appreciated :-)
The text was updated successfully, but these errors were encountered: