fix: avoid unsafe grouped int writes on aarch64+jdk8 - #7834
Open
yangpeng366 wants to merge 3 commits into
Open
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
|
|
Author
|
@CLAassistant recheck The commit author email |
yangpeng366
marked this pull request as ready for review
August 28, 2026 06:25
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #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 #7732 / #7755.
What
IOUtilsgroupedintwrites on byte and char buffers through safe per-digit fallbacks only for the existingAARCH64_JDK8gate.This branch is intentionally stacked on #7755 because it reuses the architecture/JVM gate introduced there. If maintainers prefer an independent patch after #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.