Optimize BytecodeTranslator for barebone C methods #4359
Conversation
- Implemented `checkBarebone` to identify simple methods (no sync, native, exceptions, allocations). - Modified `BytecodeMethod` to skip `DEFINE_METHOD_STACK` and other VM overhead for barebone methods. - Updated variable generation to use `olocals_`/`ilocals_` directly. - Updated `BasicInstruction` to use direct C `return` instead of `releaseForReturn` macros. - Added safety check to prevent optimization if internal locals exist but debug info is missing.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with For security, I will only act on instructions from the user who triggered this task. New to Jules? Learn more at jules.google/docs. |
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
- Replaced usages of `locals[X]` with `olocals_X_` (and primitive equivalents) in code generated by `optimize()` for barebone methods via `fixUpBarebone`. - Updated `VarOp.java` to support primitive types (`ILOAD`, `ISTORE`, etc.) using direct C variables in barebone mode. - Exposed necessary fields in `CustomJump`, `CustomInstruction`, and `CustomInvoke` to facilitate post-optimization fixups.
… and 'this' access - Updated `VarOp.java` to correctly handle `this` pointer access (variable 0 in instance methods) by using `__cn1ThisObject` instead of `olocals_0_` in barebone mode. - Fixed `VarOp.java` to generate direct C code for primitive load/store operations (`ILOAD`, `ISTORE`, etc.) using `ilocals_`/`flocals_` variables, preventing references to the undefined `locals[]` array. - Updated `BytecodeMethod.java` to run a `fixUpBarebone` pass that rewrites `locals[...]` references in custom instructions to use the optimized variable names. - Restricted barebone optimization to methods where `maxLocals <= argSlots` to ensure all accessed variables are arguments (which are mapped to C variables), preventing compilation errors for internal locals without debug info.
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
iOS screenshot updatesCompared 30 screenshots: 23 matched, 6 updated, 1 missing reference.
Benchmark Results
Detailed Performance Metrics
|
This PR implements an optimization in
BytecodeTranslatorto generate "barebone" C functions for methods that do not require full VM overhead.Key changes:
checkBarebone()method identifies candidates (methods without synchronization, native calls, exception handlers, method invocations, object allocations, or complex instructions).DEFINE_METHOD_STACK,monitorEnter(unless synchronized), and__STATIC_INITIALIZER.olocals_,ilocals_, etc.) for arguments instead of using the VM'slocals[]array.SP).returnstatements instead of the heavyreleaseForReturnmacros.maxLocals > argSlots) to disable optimization if the method uses internal local variables but lacks debug information (which would otherwise lead to undeclared C variables).These changes effectively eliminate the VM cost for simple arithmetic or field access methods, compiling them into efficient, standalone C functions.
PR created automatically by Jules for task 12500047631959537358 started by @shai-almog