Performance regression for ByteArrayMemory on Java 25
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- java
- Domain
- performance
Research direction
Read ByteArrayMemory and compare its atomic access handling with ByteBufferMemory's lock fallback. Run the multithreaded BenchmarkSievePrimes benchmark on JDK 25 to observe the reported regression; done for the immediate bug means ByteArrayMemory uses the slow lock path when atomic access is unsupported. The NativeMemory promotion is a separate, broader proposal.
Written by the indexing model from the issue text.
Description
If running the multithreaded BenchmarkSievePrimes bench on JDK 25, one can witness a radical performance breakdown. On my local machine it runs 220 times slower than on JDK 21. The reason is primarily that it calls isAccessModeSupported on every atomic read/write. On JDK 25 this throws a NoSuchMethodError internally before returning false. AFAIK there is no supported way of doing atomics on byte[] in JDK 25 and in this scenario ByteArrayMemory should fallback to the slow lock path just like ByteBufferMemory.
After fixing this, there still won't be a performant memory on JDK 25. I propose the Redline NativeMemory (or a hardened version thereof) is promoted to a neutral supported module. It still needs its own module if runtime is to remain on JDK 11. My own experimentation has shown that the native mapped memory can also give a good performance boost when using the bytecode compilers.
- Dominant language
- Java
- Stars
- 310
- Forks
- 23
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 33
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bytecodealliance/endive
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
bytecodealliance/endive#225 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
bytecodealliance/endive#211 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
bytecodealliance/endive#203 · 1 comment ·
Maintainers usually reply within 1 day
-
Redline: trampolines must be precomputed at build time; the Cranelift bridge must not be a runtime dependencyPossibly taken @andreaTP claimed this 1 day ago. Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
bytecodealliance/endive#202 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
bytecodealliance/endive#181 · 3 comments · 1 reaction ·
Maintainers usually reply within 1 day
All issues in bytecodealliance/endive
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
C21 publishes `reactivemongo/core/SSL` as Java 23 bytecode — TLS connections fail on any JDK < 23Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ReactiveMongo/ReactiveMongo#1520 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
liquid-java/liquidjava#373 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ga4gh/phenopacket-schema#465 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NationalSecurityAgency/ghidra#9748 ·
Maintainers usually reply within 1 day