Repository navigation
fix: avoid unsafe grouped int writes on aarch64+jdk8 - #21
luckylucky0001 wants to merge 3 commits into
Conversation
…baba#7732, alibaba#3763) Commit 291d744 (2.0.55) introduced UNSAFE.getLong SWAR in JSONReaderUTF16.readFieldNameHashCode for 8-char stepping with containsSlashOrQuoteUTF16 bit ops. The C2 compiler on aarch64+JDK8 miscompiles this SWAR path, causing field-name boundary errors (illegal fieldName, expect ':'). Under high concurrency the miscompiled method is cached in CodeCache, making all subsequent JSON parsing fail permanently (alibaba#3763). Fix: add AARCH64_JDK8 platform flag in JDKUtils; in the three readFieldNameHashCode* entry points, fall back to the safe char[] scanning path (readFieldNameHashCode0) when running on aarch64+JDK8. Performance impact: only affects aarch64+JDK8 field-name parsing (SWAR -> char[]). All other platforms are unaffected. Test: Issue7732 regression test with real payloads from the issue report (LoginUser, Device, SipRouteCache). Issue3763 concurrency test unchanged. Both pass on x86.
…os.arch, add !OPENJ9 Per wenshao/qwen-code review on PR alibaba#7755 (2026-08-14): * JSONReaderUTF16.readFieldNameHashCode0: drop (byte) cast so Latin-1 chars 0x80-0xFF pack unsigned, matching Fnv.hashCode64(char[], ...). Without this, parsing any UTF-16 JSON whose field name ends in 0x80-0xFF on aarch64+JDK8 mis-parses deterministically. * JDKUtils: move System.getProperty("os.arch") into the existing try/catch so SecurityException on PropertyPermission("os.arch","read") degrades gracefully instead of killing <clinit>. * JDKUtils.AARCH64_JDK8: also exclude OPENJ9 - the workaround targets HotSpot C2 miscompilation only. * JSONReaderUTF16: add comments at the three AARCH64_JDK8 guards citing alibaba#7732/alibaba#3763 and noting retirement condition (JDK 8u472+). * Issue7732: add testLatin1FieldName test for 0x80-0xFF field names plus ¼½¾ round-trip, gating the fix. Refs: alibaba#7732, alibaba#3763, PR alibaba#7755 review by wenshao
|
本机 medium 档代码评审结果 上游来源：alibaba#7834。样本：原版 PR。 结论分三种：通过；需关注（AI 意见和无法验证的内容，不阻止合并）；阻断（只在执行证据证实本 PR 引入缺陷，或仓库自己的 CI 失败时）。单条意见：已确认＝通过稳定复现、归因和证据准入的缺陷；疑似＝尚未排除、证据仍不足；待确认＝未复现、既有行为或未完成验证；团队强制规则＝命中团队规则，需人工确认。
medium 失败计数分域：PR 侧 unknown 2；基线侧失败 0 项，其中 unknown 0 项。unknown 保持原分类，不构成准入证据。 medium 基线对照：13 个文件有记录，0 个文件失败，7 个文件验证未完成。基线使用旧源码与 PR 侧相同测试，0 个文件观察到旧源码红 → PR 绿；未知失败仍需人工核查。表中“基线已失败”仅统计 PR 也出现的既有失败。 请求模型： medium · 阻断：仓库 CI 失败：Test JDK 11 on windows-latest、Test Reflect JDK 11 on ubuntu-24.04、Test JDK 21 on windows-latest、Test JDK 11 on ubuntu-24.04、Test JDK 25 on windows-latest、Test JDK 17 on ubuntu-24.04。 medium 结论
建议人工介入项不作为确认缺陷或自动修复的证据；尚未排除的疑似缺陷仍需核查。本结果只覆盖该提交、本次已执行测试与medium 档评审。 |
2 participants
Fixes alibaba#7828
Why
On affected aarch64 + JDK 8 HotSpot C2 builds, grouped integer writes through unaligned Unsafe memory operations can be miscompiled and lose digits. This is the write-side counterpart of alibaba#7732 / alibaba#7755.
What
IOUtilsgroupedintwrites on byte and char buffers through safe per-digit fallbacks only for the existingAARCH64_JDK8gate.This branch is intentionally stacked on alibaba#7755 because it reuses the architecture/JVM gate introduced there. If maintainers prefer an independent patch after alibaba#7755 lands, I can rebase/split it.
@wenshao could you help review this follow-up?
Validation
Windows x86_64 JDK 1.8.0_333 with
-DargLine=-Dos.arch=aarch64:A real affected aarch64 + Oracle JDK 8 host was not available in this environment.
Evaluation replay of alibaba#7834 (alibaba#7834). This PR stays open unless a separately authorized merge workflow runs.