Add support for ARM Cortex-A8 cores with Client VM

jgneff commented 5 years ago

Platform: Ubuntu Base 14.04.6 LTS (Trusty Tahr)

Architecture: armhf (32-bit ARM Cortex-A8 core, ARMv7-A architecture)

Processor: 800-MHz i.MX507 Multimedia Application Processor Model MCIMX507CVM8B

This is a request to add the client JVM variant to the 32-bit Linux ARM build of the JDK so that it can support the old, but still prevalent, ARM Cortex-A8 core.

In my tests with the latest JDK 13 sources, building for both the client and server variants increases the size of the installed JDK on disk by only 5.1 percent, adding less than 15 megabytes. The increase is found in two files: jmods/java.base.jmod is 4.1 megabytes larger, while the new lib/client directory takes up 10.6 megabytes.

The bug reported by JDK-8202692, "Fatal error SIGILL (ILL_ILLOPC) on ARM Cortex-A8 processor," prevents the use of the Server VM on ARM Cortex-A8 cores for JDK 12 and later. A discussion of the problem can be found in the May 2018 Archives of the mailing list, starting with the subject "C2 compiler gets SIGILL/ILL_ILLOPC".

For JDK 11, a work-around is to pass the command option -XX:-AssumeMP to the java command, but that option is not recognized by JDK 12 and later.

OpenJDK Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode):

$ ~/opt/jdk-11.0.3+7/bin/java -XX:-AssumeMP ...
OpenJDK Server VM warning: Option AssumeMP was deprecated in version 10.0 and
will likely be removed in a future release.
... [works] ...

OpenJDK Server VM AdoptOpenJDK (build 12.0.1+12, mixed mode):

$ ~/opt/jdk-12.0.1+12/bin/java -XX:-AssumeMP ...
OpenJDK Server VM warning: Ignoring option AssumeMP; support was removed in 12.0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x2b8664c4, pid=7631, tid=7632
... [fails] ...

The bug occurs only in the Server VM, so a better solution for JDK 12 and later is simply to use the Client VM:

OpenJDK Client VM (build 13-internal+0-adhoc.ubuntu.jdk, mixed mode):

$ ~/opt/jdk-13-linux-arm-clientANDserver-release/bin/java -client ...
... [works] ...

Adding the Client VM is the only way to support the ARM Cortex-A8 core in JDK 12 and later without requiring that developers build the JDK themselves.

vielmetti commented 5 years ago

If I read this right, the consumer-grade product this can be found in is the Beaglebone Black:

http://www.ti.com/tool/beaglebk

which has an A8 core in it (Sitara AM335x).

vielmetti commented 5 years ago

based on that, I found this as well: https://github.com/balena-io-library/base-images/issues/498

jgneff commented 5 years ago

I will investigate providing a pull request. It looks as if the armhf (armv7l) builds are created on native ARMv7 BareMetal Servers hosted at Scaleway in Paris. What is the reason for building on native hardware rather than using one of the following environments on a 64-bit amd64 (x86_64) computer?

the Ubuntu cross-compiling tools installed by the package crossbuild-essential-armhf
a QEMU virtual machine with the armv7l architecture

I've been cross-compiling the ARM JDK for maybe a couple years now without problems.

dwhite-marvell commented 5 years ago

There's another attempt to fix the original server JDK issue (PLDW instruction) at https://bugs.openjdk.java.net/browse/JDK-8222825

I'll email Boris and point him at this conversation.

I can imagine that there are other good reasons to providing a client JVM for arm 32, so fixing server JDK doesn't negate providing client JDK.

jgneff commented 5 years ago

There's another attempt to fix the original server JDK issue (PLDW instruction) at https://bugs.openjdk.java.net/browse/JDK-8222825

That is very good news, although I don't understand why the identical issue I reported a year ago was closed so quickly as "Not an issue." See: JDK-8202692 - Fatal error SIGILL (ILL_ILLOPC) on ARM Cortex-A8 processor.

It would be great if we can keep the JDK working on ARM Cortex-A8 cores for just a little bit longer. I find that both VMs work quite well, with the Server VM being faster but using more memory. For example, if the Client VM uses 80% CPU and 30% memory on an i.MX507 ARMv7-A processor, the Server VM can eventually get down to 55% CPU and 40% memory usage.

voitylov commented 5 years ago

BellSoft is working on a fix for this upstream OpenJDK issue https://bugs.openjdk.java.net/browse/JDK-8222825 on ARM. We connected with Jeff offline, and Jeff kindly offered help verifying the fix we have on the hardware he has got. Once confirmed, this will be submitted for OpenJDK review.

Leaving it up to the submitter and AOJDK to decide what to do with with the request to add Client VM to AOJDK.

karianna commented 5 years ago

Thanks all - I imagine we'll produce the VMs once that fix lands.

jgneff commented 5 years ago

I tested the fix for the Server VM from Boris Ulasevich at BellSoft, and it looks good so far on my ARM Cortex-A8 processor. He is making some more changes in the assertion conditions, so I'm waiting for his next update.

I think it might still be useful to have the Client VM in the arm JDK for the following reasons:

It's nice to have a backup VM in case an error like JDK-8202692 ever shows up again.
My test program takes a hit in its performance with the Server VM after running for about 20 minutes as the C2 compiler, I'm guessing, does its magic. After that brief performance hit, the overall CPU usage eventually drops by about 10 percent. The test program is an animation, though, so you can actually see the drop in the frame rate during the transition. I tried to force all such optimizations at startup time with -XX:-TieredCompilation, but I didn't notice a difference.

Even though the Client VM uses about 10 percent more CPU usage, the performance remains constant, so it may be preferred for some applications.

I'm still working on a pull request, which might be just a one-line change.

What is the reason for building on native hardware ...?

To answer my own question ...

My native builds for x64 on x64 take 18 minutes.
My cross-compile builds for arm on x64 take 20 minutes.
My native builds for arm on arm using a QEMU virtual machine take 17 hours 22 minutes.
And my actual ARM device is about 40 percent slower than my QEMU virtual machine!

Meanwhile, the AdoptOpenJDK builds on the Scaleway ARMv7 BareMetal Servers take only 1 hour 25 minutes. Also, the build scripts only work for native builds because they download or build other software on the machine (Alsa, Freetype, Freemarker, CaCerts), and because they run the target JDK at the end of the build to output its version strings.

jgneff commented 5 years ago

Now I consistently get the same error as #1004, and the workaround that I remember using yesterday (temporarily using JDK 12 for the boot JDK) doesn't work today. Even if I download the gradle-5.2.1-bin.zip file manually, it just fails later on trying to get https://repo.maven.apache.org/maven2/org/codehaus/groovy/groovy-all/2.5.6/groovy-all-2.5.6.pom. Any ideas?

Edit: The work-around of using JDK 12 for the boot JDK is actually working after all. (Turns out I was still using JDK 11 before.)

hariszaf commented 5 years ago

Hi everyone!

I have made a Singularity image using jdk-11.0.2+7 on it.

I am trying to run a tool called Trimmomatic inside the image and while for over 20 different samples it is running as it should, in a specific one I get the following error:

# A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x00007f51c8695367, pid=5762, tid=5819 # # JRE version: OpenJDK Runtime Environment (11.0.2+7) (build 11.0.2+7) # Java VM: OpenJDK 64-Bit Server VM (11.0.2+7, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # J 784 c2 org.usadellab.trimmomatic.trim.IlluminaClippingTrimmer$IlluminaLongClippingSeq.readsSeqCompare(Lorg/usadellab/trimmomatic/fastq/FastqRecord;)Ljava/lang/Integer; (306 bytes) @ 0x00007f51c8695367 [0x00007f51c8693e40+0x0000000000001527] # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://github.com/AdoptOpenJDK/openjdk-build/issues #

It is really strange to me, as it is returning this error only with a specific file while this file has exactly the same format with all the others..

Do you have any idea why I may get this error?

Thank you in advance, Haris

jgneff commented 5 years ago

@hariszaf The problem described in this GitHub issue occurred only on a 32-bit ARM processor, while it seems you're using a 64-bit Intel or AMD processor. You might want to post your question to one of the OpenJDK mailing lists or report the error with the JDK Bug System.

schirrel commented 3 years ago

How far is this going? is https://bugs.openjdk.java.net/browse/JDK-8202692 fixed? I'm having this issue on beaglebone black, https://beagleboard.org/black.

jgneff commented 3 years ago

is https://bugs.openjdk.java.net/browse/JDK-8202692 fixed?

Yes, that bug was fixed with JDK-8222825, "ARM32 SIGILL issue on single core CPU (not supported PLDW instruction)," in OpenJDK 13. And this specific issue report for the AdoptOpenJDK build was also fixed by adding the Client VM to the build.

I'm having this issue on beaglebone black, https://beagleboard.org/black.

The original error that lead to this issue was an unsupported PLDW instruction. Is that what you're seeing? If you're just getting another SIGILL fatal error, you should report it in the Java Bug Database.

adoptium / temurin-build

Add support for ARM Cortex-A8 cores with Client VM #1070