On Sep 28, 2016, at 1:55 PM, Volker Simonis <volker.simonis@gmail.com> wrote:

Hi Bob,

congratulations! I'm pretty sure this was a pretty huge amount of paper and programming work to reach this point :)

My general question is how is this code contribution supposed to work together with the current ARM ports in the OpenJDK. Currently we have a full-blown, supported arm64 bit port in the jdk9 main-line (contributed and maintained by RedHat). The aarch32 project has a full-blown implementation for arm32 for jdk8u contributed by Azul. I didn’t think the arm32 project had a C2 server VM yet?

Is your new port intended to live and be maintained alongside these already available ports? At this point we are simply offering to contribute our ARM implementations to the community and no decisions on consolidation of ports has been decided.

Where does your port differ from the available ports in terms of functionality and performance? The primary reason for putting the webrev out in the open is to allow for the review of our implementation by the aarch32 project team.

ARM32 Our 32-bit ARM port is very mature and has been around for over 8 years. These sources support several 32-bit ARM architecture versions including ARMv5, ARMv6 and ARMv7 with VFP hard-float, soft-fp and full soft-float floating point support. Both 32 and 64 bit ARM ports support the building of the minimal, client and server hotspot VMs. We also support the compilation of native binaries with thumb2. AARCH64 Our AARCH64 bit port is fully functional and supports the same three VM combinations. MAINTAINABILITY As you can see from the sources, we designed the ARM ports to share as much of the sources for 32 and 64 bit ARM support as possible making it easier to maintain and add CPU specific features to hotspot. This design philosophy is consistent with our sparc and x86 ports. PERFORMANCE I have not done a performance comparison of the existing open ports. Note: Some of the Oracle commercial features may not be fully supported on some of the ARM platforms.

Is Oracle committed to support the new ports? Oracle is committed to producing 32 & 64 bit ARM binaries for at least the JDK 9 product life cycle. We will be producing our ARM binaries from our closed sources for JDK 9.0.

And finally, do you expect to integrate these ports into JDK 9 mainline? I would like to work with the aarch32 project team towards that goal.

Bob.

Thanks a lot and best regards, Volker

On Wed, Sep 28, 2016 at 4:07 PM, Bob Vandette <bob.vandette@oracle.com> wrote:

...

I’m am please to announce that I have completed our internal reviews and can now open up the sources to our ARM 32 & 64 bit implementations of JDK9.

Here is a webrev that includes a patch that can be applied on top of the (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.

http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>

Notes:

1. Counter to my initial email announcing the open sourcing effort, the pregenerated interpreter is not included in the provided patch. AOT is our long term solution for increased performance on Mobile and it was decided that we do not want to support the static interpreter beyond JDK 8.

2. In order to allow building the two different 64-bit ARM sources, I overloaded a new configure option —abi-profile to allow for the selection of the Oracle 64-bit ARM port. We need a better solution before this support can be integrated into the mainline. To use the Oracle sources for an aarch64 build, select —abi-profile=arm64.

3. The scripts provided below allows for the creation of the minimal, client and server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not automatically updated during the build. To run a non server VM, this file will need to be updated.

4. In order to make it easier to keep the new open sources up to date with their closed counterparts in jdk9, I have added a comment in hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial revision that I last merged with. This will make it easier to produce patches to bring the new open files up to the latest version.

/* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */

Build Scripts:

Here are a set of scripts that demonstrate how to build the three ARM configurations. We typically cross compile our ARM builds so these scripts will have to be adjusted in order to build natively on an ARM system.

http://cr.openjdk.java.net/~bobv/arm3264/scripts/ <http://cr.openjdk.java.net/~bobv/arm3264/scripts/>

aarch64.csh Builds the current open version of aarch64 binaries arm64.csh Builds the Oracle aarch64 binaries arm.csh Builds 32-bit ARM binaries

My next step is to push this changeset into the jdk9-arm3264 forest assuming I achieve committer status for the aarch32 project this week.

Bob Vandette

On Sep 30, 2016, at 7:23 AM, David Holmes <David.Holmes@oracle.com> wrote:

Hi Ed,

On 30/09/2016 8:32 PM, Edward Nevill wrote:

...

Hi Bob,

On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote:

...

I’m am please to announce that I have completed our internal reviews and can now open up the sources to our ARM 32 & 64 bit implementations of JDK9.

Great news.

...

Here is a webrev that includes a patch that can be applied on top of the (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.

http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>

I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination.

I have also tested the server build with JTreg hotspot & langtools.

On aarch64 I got the following results:-

hotspot: Test results: passed: 1,280; failed: 8; error: 43 langtools: Test results: passed: 3,700; failed: 1; error: 29

This is fairly typical, for example, using the Linaro 1609 build I get

hotspot: Test results: passed: 1,271; failed: 17; error: 43 langtools: Test results: passed: 3,715; failed: 3; error: 12

So most of the "errors" are probably tests that are ignored.

...

On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough).

However, I then had problems with the test harness crashing with the error

# Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542 # guarantee(mid->header()->is_neutral()) failed: invariant

(hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log)

Strange - that looks like our closed bug:

https://bugs.openjdk.java.net/browse/JDK-8071540

which should be fixed. It was a missing memory barrier issue.

I checked and this fix was applied but later a newer implementation was added. The memory barriers were moved to cas_for_lock_acquire with optimized versions for aarch64. Be aware that G1 support on 32-bit ARM is not fully supported by the GC team. It’s experimental. This means that there was an attempt to implement it but it has not undergone the same level of testing as other platforms. I’ll forward this issue to the GC team. Bob.

Aside: we're going to have to figure out how to deal with currently closed bug reports.

David -----

...

On a subsequent run the test harness locked up after 85 tests.

It looks like there might be a problem with locks breaking with G1GC. I will keep investigating.

I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully.

On armv7 I got

hotspot: Test results: passed: 1,202; failed: 11; error: 36 langtools: Test results: passed: 3,718; failed: 5; error: 8

I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing.

Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge.

All the best, Ed.

Hi Bob, The 32-bit ARM early access binaries are client only. I only see the problems with the server JIT. All the best, Ed. On Fri, 2016-09-30 at 10:03 -0400, Bob Vandette wrote:

Ed,

Could you try the 32-bit ARM binaries from the early access page to see if the G1GC problem reproduces? 

https://jdk9.java.net/download/

Bob.