Repository navigation
Store the constant pool in typed arrays, about 8 MB less heap per javac VM - #60
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 26 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. |
There was a problem hiding this comment.
The PR replaces the constant pool representation from an array of objects to three typed arrays (Uint8Array for tags, Uint32Array for packed a/b operands, and a regular array for UTF-8 strings and numeric values). This reduces heap usage by ~8 MB per javac VM. All five modified files (classfile.ts, indy.ts, jit.ts, jvm.ts, npe.ts) have been consistently updated to use the new accessor functions (cpTag, cpA, cpB, cpValue, utf8). The parsing logic correctly handles Long/Double double-slot entries and index 0. No bugs or logic errors are present in the diff.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
A library VM uses about 8 MB less heap after a javac compile. The constant pool now lives in typed arrays instead of one object per entry.
Each parsed class kept its constant pool as an array with one
{ tag, value, a, b }object per non-UTF-8 entry, about 156,000 objects in a javac VM. Now each class has:tags, aUint8Array,ab, aUint32Arrayholding the two u16 operands of each entry,values, holding UTF-8 strings and numbers.The interpreter, JIT and invokedynamic code read the arrays through
cpTag,cpA,cpBandcpValue.cpEntrystill builds an entry object for the few reflection natives that want one.Heap after a forced gc, master to this branch, median of 3:
Time: whole runs (hello world start, a javac compile, the test suite) stay within run-to-run noise. In microbenchmarks, parsing is 3 to 5% slower, and constant pool reads during resolution are about 3 times faster.
Tests:
pnpm typecheckandpnpm testpass.