Repository navigation
perf(jit): emit 13% less JS and keep less per method, cutting javac's heap by 13% - #88
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 37 minutes. View limit details
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. |
… guard-miss calls javac compiling 30 files: generated JS 9.43 MB to 8.22 MB (2491 methods), heap after a run 167 MB to 160 MB (median of 3 each). - one constant slot per value instead of one per use - the slow tail of a call takes its exit codes from slowCall - a call after a failed inlining guard goes through rt.callv - no null check on `this`, or on a receiver already class-guarded - deopt frames name the callee once, and return tails pass one letter
…able table only when read javac compiling 30 files, heap used after a run: 161.4 MB to 154.1 MB (median of 3). A snapshot showed 61k Uint8Array views and 15k attribute maps; most methods are never run or reflected on.
… be inlined javac compiling 30 files, heap used after a run: 154.1 MB to 146.7 MB (median of 3). The analysis sets and maps of every compiled method were kept for the life of the VM.
…nd weak CAS as natives Microbenchmark, median of 5 processes: AtomicInteger.incrementAndGet x1M 373 ms to 128 ms, AtomicLong.addAndGet x1M 280 to 153 ms, AtomicReference.getAndSet x1M 446 to 347 ms. HotSpot intrinsifies the same methods; here they were Java loops over the volatile natives.
…ew per array A heap ByteBuffer or VarHandle view over a fresh byte[] made a DataView for it; short-lived arrays now go through byte arithmetic and a shared scratch.
ee8a211 to
8841153
Compare
![project516-review-bot[bot]](https://avatars.githubusercontent.com/in/4903871?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR reduces heap usage by 13% through lazy parsing of classfile attributes (bytecode, LocalVariableTable, member attrs), JIT optimizations (constant sharing, shared slow-call exits, out-of-line guard-miss calls, null-check elimination via non-null tracking), and native implementations of Unsafe ordered/weak atomics plus byte[] composed access. Tests pass (251/0/3). The changes are largely correct but two areas need verification: the 4-argument limit in callv and the H.deliver type-character change.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
|
On the two points in the review summary, both checked against the code:
|
What this changes
The JIT emits less JavaScript and the VM keeps less per method, so javac and other large programs use less heap; a few hot JDK paths get faster natives.
thisand on a receiver a class guard already checked. Generated JS for javac compiling 30 files: 9.43 MB to 8.22 MB (-13%).LocalVariableTableare built only when read, and a compiled method's analysis is dropped unless the method can be inlined.Unsafe's acquire, release and opaque accessors,getAndAdd,getAndSetand weak CAS run as natives, as HotSpot intrinsifies them. Threads never interleave inside a native here, so each is a plain read and write.byte[]reads and writes of wider values compose bytes instead of making aDataViewper array.Tests
Heap and time measured master against branch, alternating runs:
AtomicInteger.incrementAndGet, 1M calls: 373 ms to 128 ms.ByteBuffer.wrap(new byte[16]), 300kputLong/getLong: 661 ms to 593 ms.TransferTo211 to 137,UUIDTest329 to 221,EntryCount64k70 to 66;CollisionsandZipFileSharedSourceTestshow no change beyond the spread.JitGuardMiss,ReflectAttrs,UnsafeAtomics,ByteArrayViews.passing.txtOpenJDK tests under the touched directories pass.Noticed, not fixed
implCompress0is not a native yet and shows up hot in profiles of tests that hash a lot.enter, the run loop) andConcurrentHashMap.tabAtloops remain the largest costs in the slow tests.