JDK-8216989 : CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version:
    8-aarch64,8-shenandoah,11,11-shenandoah,12,13 8-aarch64,8-shenandoah,11,11-shenandoah,12,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2019-01-14
  • Updated: 2021-02-01
  • Resolved: 2019-03-25
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 13 Other
11.0.11-oracleFixed 13 b14Fixed openjdk8u292Fixed
Related Reports
Relates :  
Description
If an arraycopy of length zero is performed on AArch64, one byte is dirtied regardless in the card table. The card being dirtied could in the worst case be out of bounds with the committed memory for the card table, and cause a crash.
Comments
Fix Request JDK11u What: The original patch failed to match at one point because an assert was not present. Also, changes to upstream shenandoah barrier abstraction code were omitted because the barrier abstraction is not yet backported to jdk11u. Why: This avoids a potential crash Review Thread: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001746.html Testing: tier1 tests complete as before
26-08-2019