Repository navigation
Faster VarHandle, Unaligned and AES paths for NoSync - #21
Conversation
…ctly, as HotSpot's folded guard does.
…ch array's DataView to the array.
 |
| Layer / File(s) | Summary |
|---|---|
VarHandle call caching src/jit.ts, test/java/VarHandles.java |
VarHandle guard calls cache eligible implementations and use direct entry when available, with a run-loop fallback. The new test exercises shared call sites, type mismatches, and bounds checks. |
AES block encryption src/natives/crypto.ts, test/java/CryptoMath.java, AGENTS.md, test/jtreg/passing.txt |
The crypto natives register AES block encryption with per-JVM cached tables and key-schedule slots. Tests cover three key sizes, three cipher modes, decryption, and overlapping ranges. The jtreg list adds NoSync.java. |
Unaligned primitive access src/natives/misc.ts, test/java/Unaligned.java |
The runtime caches primitive-array DataViews and adds unaligned Unsafe reads and writes with native or explicit byte order. The test covers byte-array views and heap and direct buffers. |
Estimated code review effort: 3 (Moderate) | ~25 minutes
Change: Refactor
Sequence Diagram(s)
sequenceDiagram
participant GeneratedVarHandleCall
participant runtime.vhTarget
participant VarHandleCache
participant JITCompiledImplementation
participant RunLoop
GeneratedVarHandleCall->>runtime.vhTarget: Populate cache on a miss
runtime.vhTarget->>VarHandleCache: Store eligible handle and member implementation
GeneratedVarHandleCall->>VarHandleCache: Check receiver and retrieve implementation
VarHandleCache-->>GeneratedVarHandleCall: Return cached implementation on a match
GeneratedVarHandleCall->>JITCompiledImplementation: Directly enter when eligible
GeneratedVarHandleCall->>RunLoop: Call matching handle when direct entry is unavailable
Possibly related issues
- Project516/java-web issue 15: The PR adds AES and JIT/runtime paths and restores the NoSync test entry, which relates to the issue’s NoSync runtime objective.
- Project516/java-web issue 42: The PR adds runtime fast paths and restores the NoSync test entry, matching the issue’s release-checklist requirement for speed work.
Possibly related PRs
- Project516/java-web#14: This PR restores the same NoSync test entry after PR
#14removed it due to runtime. - Project516/java-web#8: Both PRs address NoSync execution time; PR
#8changes the jtreg timeout, while this PR changes runtime paths used by the test. - Project516/java-web#12: PR
#12defines howpassing.txtdrives jtreg selection, and this PR adds NoSync to that list.
Suggested reviewers: project516-review-bot
Merge Risk: 
12ec0
-
No blocking defect is demonstrated; non-byte-array coverage would improve confidence.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 45.45% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documenta… Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Title check The title names three changed areas: VarHandle call sites, Unsafe unaligned accessors, and AES. The changeset matches each area: jit.ts adds the VarHandle one-entry cache, misc.ts adds the unaligned i… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Description check The description directly explains the VarHandle, Unsafe unaligned access, AES intrinsic, test, performance, and validation changes in the pull request. Full details: Title check
-
Explanation
The title names three changed areas: VarHandle call sites, Unsafe unaligned accessors, and AES. The changeset matches each area: jit.ts adds the VarHandle one-entry cache, misc.ts adds the unaligned intrinsics, and crypto.ts adds AESCrypt.implEncryptBlock. The title does not name the main goal (speeding up NoSync), but it is not off-topic or vague.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 45.45% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 11 functions across 6 files. (2 skipped: 2 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches
-
Generate docstrings
-
- Commit to this branch
- Create a new PR
Simplify code
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit taps a byte in place,
Then checks the cipher’s steady pace.
A handle finds its cached way,
While little paws test night and day.
The burrow’s list now lets NoSync play.
CodeRabbit Verify
- Run CodeRabbit Verify to test the changes in this pull request.
There was a problem hiding this comment.
This PR adds three performance optimizations for the NoSync SecureRandom path: (1) VarHandle call site caching in the JIT to avoid repeated guard checks, (2) Unsafe unaligned access intrinsics using DataView for direct memory access instead of byte-by-byte assembly, and (3) an AES encryption intrinsic using T-tables. All three mirror HotSpot's intrinsic strategies. Tests cover VarHandle polymorphism, exact handles, unaligned access at every alignment and byte order, and AES round trips.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
…oned array's view.
There was a problem hiding this comment.
This PR adds three performance optimizations: VarHandle call site caching in the JIT (vhTarget), Unsafe unaligned access intrinsics using DataView, and an AES encryption intrinsic. The VarHandle cache stores the last handle and its implementation when the guard would link directly. Unaligned accessors use a cached DataView per primitive array for single-instruction reads/writes. AES implEncryptBlock is implemented with T-tables. Tests cover VarHandle polymorphism, unaligned access at all alignments, and AES modes.
Not approved: 4 earlier points are still open in the threads.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict comment
There was a problem hiding this comment.
This PR adds three JIT/runtime optimizations: (1) VarHandle call-site caching that folds the guard and calls the implementation directly when the handle and AccessDescriptor match, (2) Unsafe unaligned access intrinsics using DataView for single native-order reads/writes instead of byte-by-byte assembly, and (3) an AES encryption intrinsic (implEncryptBlock) using T-tables. The changes are focused on the NoSync SecureRandom path. Tests cover VarHandle polymorphism, exact handles, unaligned access at all alignments/orders, and AES round-trips. The settled points (reference-array bug in unaligned predicate, DataView clone sharing, convEndian shared scratch, VarHandle final-class assumption, AES bounds-check comment) are known and not raised here.
Not approved: 1 earlier point is still open in the threads.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict comment
Closes #15.
java/security/SecureRandom/NoSync.javaspent its time around the SHA and AES work, not in it. This PR does what HotSpot does there:ByteArrayAccesswrites each digest word through a byte-array view VarHandle. Every write went throughVarHandleGuards.guard_*,checkAccessModeThenIsDirectandVarForm.getMemberName. A compiled call site now keeps the handle it saw last and calls the handle's implementation directly, as HotSpot's folded guard does. The cache is filled only when the guard would link straight to the implementation: a direct handle, the site's erased type matching, and, for an exact handle, its type check already passed. Exact handles matter becauseByteArrayAccessuses them.get/put{Long,Int,Short,Char}Unaligned, with and without the byte-order flag, are intrinsics (as in HotSpot): one DataView access instead of byte-by-byte assembly and an extraconvEndiancall. Each primitive array keeps its DataView inJArray.x.AESCrypt.implEncryptBlockis an intrinsic, like the SHA ones incrypto.ts. CTR_DRBG only encrypts, so decryption stays as bytecode.NoSync on a small ARM board, two cores:
It took 95 s there through the jtreg runner, beside another test, and 56 s on a CI runner (it was 521 s), so it returns to
passing.txt.Tests, all compared with HotSpot:
test/java/VarHandles.java: field, static, array and byte-view handles in compiled code; one call site fed alternating handles; exact handles that pass or throwWrongMethodTypeExceptionat a shared site; out-of-bounds accesses.test/java/Unaligned.java: byte-array views at every alignment, both byte orders, and heap, direct and view buffers.test/java/CryptoMath.javagains AES-128/192/256 in ECB, CBC and CTR, with decryption round trips and an in-place overlapping encrypt.Verified:
pnpm test,pnpm typecheck, the SecureRandom OpenJDK tests through the jtreg runner. CI runs every OpenJDK test, since the JIT changed.