RFR: 8220566: AArch64: Set default vm features for Ampere eMAG CPUs

Patrick Zhang OS patrick at os.amperecomputing.com
Thu Mar 14 04:05:21 UTC 2019

Hi Andrew

I added below comments in JIRA, also copied here. Thanks for your review.

These three flags had been verified on Ampere eMAG platform with a couple of benchmarks and apps
AvoidUnalignedAccesses=TRUE, UseSIMDForMemoryOps=TRUE can bring positive impact consistently, since access to odd alignment memory is not what we expect, and simd instructions replacement for mem/array copying practically helps performance.
While for UseSIMDForArrayEquals=TRUE (default), I am not quite sure yet what took more execution time, either ld1 or umov, or the sequence generated inside generate_large_array_equals_loop_simd. Therefore I make it FALSE within a stricter condition for CPU revisions I have so far.


-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Wednesday, March 13, 2019 6:27 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8220566: AArch64: Set default vm features for Ampere eMAG CPUs

Hi Patrick,

On 13/03/2019 10:11, Patrick Zhang OS wrote:
> Please help review this patch for setting default vm features specifically for Ampere eMAG CPUs.
> Webrev: http://cr.openjdk.java.net/~qpzhang/8220566/webrev.01
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220566
> Tested with Ampere eMAG platforms, jtreg jdk_core and jcstress, etc.
The patch looks like it might be ok. However, that's hard to say because the JIRA issue simply restates what is in the  patch i.e. that these specific code changes are needed.

Could you add a note on the JIRA issue explaining why these configuration options are preferred? At that point it will be possible to review the patch.


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the hotspot-runtime-dev mailing list