JDK-8159052 : AArch64: Optimise unaligned copies in pd_disjoint_words and pd_conjoint_words
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: aarch64
  • Submitted: 2016-06-08
  • Updated: 2021-02-02
  • Resolved: 2018-08-28
Related Reports
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Description
The asm vsns of pd_disjoint_words and pd_conjoint_words are not optimised for unaligned accesses.

Some partners' HW has large penalties for unaligned accesses.

This issue proposes opimising pd_disjoint_words and pd_conjoint_words for unaligned access.

Performance on platforms which support unaligned accesses without penalty should not be affected by this change.
Comments
URL: https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/f57189b7648d User: andrew Date: 2021-02-02 05:24:08 +0000
02-02-2021
URL: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/f57189b7648d User: andrew Date: 2021-02-01 20:00:27 +0000
01-02-2021
This is problematic for a number of reasons and only affects some hardware with poor handling of unaligned copies. It's better for the stability of the platform not to fix this.
28-08-2018
[~enevill] The alignment requirement that is being asserted by the public API is "word" alignment, e.g. 4 bytes in a 32bit build and 8 bytes in a 64bit build. (A 32bit build could potentially be run on 64bit hardware, and perhaps see a penalty. But since this change is for aarch64, which is 64bit only, that isn't an issue.) The measurement results are interesting though, and suggest there might be something else going on that could be worth investigating further by the relevant platform owners.
16-10-2017
Hi Kim, Unaligned here refers to 64 bit alignment. Some ARM HW has large penalties copying data that is 4 byte aligned, but not 8 byte aligned. However I can find no traction for making this change so I am quite happy to see this closed. All the best, Ed.
16-10-2017
I think there is something else going on here, and that the proposed change to support unaligned copies by the word copy functions should not be made. pd_disjoint_words and pd_conjoint_words provide the private implementations of the corresponding Copy::{disjoint,conjoint}_words. That public API has a precondition that the pointers are word-aligned, with asserts to ensure that in debug builds. Hence the pd_ functions never (that I could find) get called with unaligned arguments. If the pd_ functions *are* somehow called with unaligned arguments, *that* is a bug and should be fixed. As to why the test timings showed some improvement from the proposed change, I have no idea. Perhaps the process of adding unaligned support "accidentally" fixed some lurking performance bug in the existing code. Or maybe just measurement issues; trying to decently measure something low-level like this by running some Java stress test is difficult. It would be better to directly measure the differences using a focused low-level test, perhaps written using the gtest facilities.
16-10-2017
Is this change going to be completed for jdk 10?
08-05-2017
To me it seems that pd_disjoint_words and pd_conjoint_words have a large set of users (not just the compiler or compiler-related components). Therefore it is most likely better to address this issue within the runtime (and not compiler).
13-02-2017
This has been pushed the aarch64 jdk8u but not to jdk9 webrev is here http://cr.openjdk.java.net/~enevill/8159052/webrev/ Last comment on the aarch64 list was http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-June/003530.html
18-08-2016
Moving this RFE to jdk 10 since there is no FC extension request for jdk 9.
15-08-2016
Moving to compiler since it will be pushed into hs-comp.
01-08-2016
webrev: http://cr.openjdk.java.net/~enevill/8159052/webrev/
01-08-2016
[~enevill] Do you still plan to push it into JDK 9? You need FC exemption request then.
01-08-2016