JDK-8217467 : Access barriers are missing in C2 intrinsic for Base64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11-shenandoah,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-01-21
  • Updated: 2019-08-15
  • Resolved: 2019-01-22
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 12 JDK 13
12 b29Fixed 13Fixed
Related Reports
Relates :  
JDK-8205528 - Base64 encoding algorithm using AVX512 instructions
Relates :  
JDK-8210187 - Explicit barriers for C2
Description
New Base64 intrinsics code introduced by JDK-8205528 is missing GC interface accesses. This was found in Shenandoah CTW tests:
 https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-January/008790.html

It can theoretically affect other GCs as well. C2 interface was introduced in 12, so both 12 and 13 are affected.

Sample fix:
 http://cr.openjdk.java.net/~shade/shenandoah/fix-base64.patch
Comments
closed/not verified, the problem was found by ShenandoahVerifyOptoBarriers, and can't be verified w/o it.
12-02-2019
[~kvn], please ack the RFR at hotspot-compiler-dev? Link above.
22-01-2019
[~shade] Good. You can push then.
22-01-2019
I ran current patch on my SKL-X desktop (where I know that intrinsic path is exercised) with: ~/trunks/jdk-jdk12$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=compiler/intrinsics/base64/ TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions ..." CMS, G1, Epsilon, Serial, Shenandoah, Parallel, ZGC -- all fine!
22-01-2019
:( There are some avx512 in Mach5 but if tests did not scheduled on them we are out luck. Can you run compiler/intrinsics/base64 on avx512 machine with all GCs to make sure they work? I think it will be enough.
22-01-2019
[~kvn] My suspicion there are no machines in Mach5 support AVX-512, and so this intrinsic does not even fire. I made the accidental error in my initial patch, and tier1 did not fail in jdk-submit, while hotspot tier1 (compiler/intrinsics/base64) had failed on my local machine. Do you think it is still useful to run Mach5 tier3 then?
22-01-2019
[~shade] I would suggest you before push to ask someone from Oracle's GC group to run Mach5 tier3 where all GCs are tested.
22-01-2019
Fix request approved.
22-01-2019
Fix Request --------------------------------- This fixes the critical failure in new Base64 intrinsics (since 11) and new concurrent collectors (since 12 [Shenandoah]). The fix follows the same way other intrinsics are handled, and it is verified by Shenandoah CTW tests. Having it in 12 saves users from being exposed to a hard-to-detect GC bug.
22-01-2019
RFR: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032340.html
22-01-2019
Targeting this for JDK 12 for now because the fix is ready and simple. [~shade], do you plan to take care of integration or should this be re-assigned? Please note JDK 12 fixes now require approval: http://openjdk.java.net/jeps/3#Fix-Request-Process
22-01-2019
ILW = Missing access barrier, in Base64 C2 intrinsic (currently only affects Shenandoah), disable intrinsic or use different GC = HMM = P2
22-01-2019