Fwd: Webrev of Oracle ARM & AARCH64 Sources

dean.long at oracle.com dean.long at oracle.com
Mon Oct 3 19:15:38 UTC 2016


It could be something simple like os::is_MP() returning false, but then 
I would expect a lot more tests to fail.

dl


On 9/30/16 1:14 PM, Bob Vandette wrote:
> I realize that we don’t officially support G1GC for ARM but here’s a 
> crash running
> the test harness using G1GC on a 32-bit ARM server VM in case anyone has
> any insights.
>
> Bob.
>
>
>> Begin forwarded message:
>>
>> *From: *Bob Vandette <bob.vandette at oracle.com 
>> <mailto:bob.vandette at oracle.com>>
>> *Subject: **Re: Webrev of Oracle ARM & AARCH64 Sources*
>> *Date: *September 30, 2016 at 9:58:55 AM EDT
>> *To: *David Holmes <David.Holmes at oracle.com 
>> <mailto:David.Holmes at oracle.com>>
>> *Cc: *edward.nevill at gmail.com <mailto:edward.nevill at gmail.com>, 
>> aarch32-port-dev at openjdk.java.net 
>> <mailto:aarch32-port-dev at openjdk.java.net>, 
>> "hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net> 
>> developers" <hotspot-dev at openjdk.java.net 
>> <mailto:hotspot-dev at openjdk.java.net>>, 
>> aarch64-port-dev at openjdk.java.net 
>> <mailto:aarch64-port-dev at openjdk.java.net>
>>
>>
>>> On Sep 30, 2016, at 7:23 AM, David Holmes <David.Holmes at oracle.com 
>>> <mailto: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/%7Ebobv/arm3264/webrev> 
>>>>> <http://cr.openjdk.java.net/~bobv/arm3264/webrev 
>>>>> <http://cr.openjdk.java.net/%7Ebobv/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 
>>>> <http://cr.openjdk.java.net/%7Eenevill/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.
>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20161003/e6a74b28/attachment.htm>


More information about the hotspot-gc-dev mailing list