JDK-8270947 : AArch64: C1: use zero_words to initialize all objects
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2021-07-20
  • Updated: 2022-11-18
  • Resolved: 2021-07-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 18
11.0.18-oracleFixed 17.0.6-oracleFixed 18 b09Fixed
Related Reports
Relates :  
JDK-8271956 - AArch64: C1 build failed after JDK-8270947
Relates :  
JDK-8272791 - java -XX:BlockZeroingLowLimit=1 crashes after 8270947
Relates :  
JDK-8272094 - compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline"
Relates :  
JDK-8270830 - Aarch64: Use stp to initialize object on C1
Relates :  
JDK-8280234 - AArch64 "core" variant does not build after JDK-8270947
Relates :  
JDK-8287129 - TestStressCodeBuffers.java crashes on macosx_aarch64
Description
C1 has its own code generators for zeroing words. We should rip them out and use MacroAssembler::zero words which was written for C2. It's shorter and faster and there's less code to maintain.
Comments
[11u] I'll remove the tag. Please label again when needed.
18-11-2022
Thanks for the feedback. It's reasonable. I will seek more evidences. I will put those PRs on github on hold for the time being.
14-11-2022
Two things: Firstly, large object allocation is usually rare. We'd need to see a substantial improvement to real-world code. Secondly, this patch is intrusive and not of low risk. It's a tricky patch and needs to be reviewed very carefully, if and only if we can see a substantial real-world improvement. Feel free to measure warm-up time, and we'll take the discussion from there.
11-11-2022
hi, ~aph Thank you for the pointer. I updated the wordings above. I think the primary consideration is for parity of oraclejdk11u. This is cleanup and also performance enhancement for C1 on aarch64. jdk11u users can gain 30%+ throughput in large allocations in object initialization. Given the prevalence of object initialization in warm-up phase of a java process, I think the benefit is substantial for jdk11u users.
10-11-2022
Fix request [11u] We would like to backport this to jdk11u for parity with oraclejdk11u. It's not only less code to maintain, but also better generated code. C1 can leverage DC ZVA in large allocations on aarch64. This isn't a clean backport. Small cosmetic changes are made in MacroAssembler::zero_words(Register ptr, Register cnt) chunk. There are also 3 trailing bugfixes. We will post them together as stacked PRs. We drop JDK-8280234 because current openjdk11u doesn't support variant 'core'. The risk is low. We have tested the PatchSet for both jtreg and JCK.
10-11-2022
Please review the "Fix Approvals" criteria at https://wiki.openjdk.org/display/JDKUpdates/JDK11u. In particular, please explain how this patch provides substantial benefit to OpenJDK 11u users and is of low risk.
09-11-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1502 Date: 2022-11-04 17:59:57 +0000
04-11-2022
This looks reasonable for 17 LTS, at least in this stage of the 17u life cycle.
18-10-2022
Fix request [17u] I backport this for parity with 17.0.6-oracle. A bigger aarch change, mostly a performance optimization and cleanup. I would take this to 17, at least, to keep the port close to head. There are several follow-ups, but this has hung for a year and 3 months now, should be good. Clean backport. Test mentioned in 8272094 passes (including that change). SAP nightly testing passed.
18-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/792 Date: 2022-10-14 13:25:23 +0000
14-10-2022
The patch for JDK-8272094 must be applied if this change is ever to be backported.
17-05-2022
To anyone contemplating backporting this one, beware: it caused the regression in JDK-8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline".
17-05-2022
If this proves to be a good patch, we might consider doing the same in JDK Updates, marking as such.
02-08-2021
Changeset: 6c68ce2d Author: Andrew Haley <aph@openjdk.org> Date: 2021-07-30 18:02:11 +0000 URL: https://git.openjdk.java.net/jdk/commit/6c68ce2d396c6fe02201daf2bdb8c164de807cc1
30-07-2021