Webrev of Oracle ARM & AARCH64 Sources

[Bob Vandette]

> On Sep 30, 2016, at 7:23 AM, David Holmes <David.Holmes at 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.
>> 
>>