[code-reflection] RFR: BytecodeGenerator cleanup and switch support [v14]

Adam Sotona asotona at openjdk.org
Thu Dec 4 14:26:57 UTC 2025


On Thu, 4 Dec 2025 13:27:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The current `BytecodeGenerator` implementation assumes that code models have already been lowered before generation. Both `SwitchExpressionOp` and `SwitchStatementOp` with all-constant labels are examples of operations that can be lowered an alternative way, allowing `BytecodeGenerator` to produce more efficient bytecode using `tableswitch` and `lookupswitch` instructions. 
>> 
>> The proposed change shifts the responsibility for lowering these operations into the `BytecodeGenerator` itself, enabling selective lowering during bytecode generation. Consequently, `OpBuilder` and `BytecodeGenerator` tests have been updated to avoid invoking the lower transformation step before the `BytecodeGenerator` is called. 
>> 
>> A new internal operation, `ConstantLabelSwitchOp`, has been introduced. This acts as an intermediate representation for lowered `SwitchExpressionOp` and `SwitchStatementOp` instances with constant labels. 
>> 
>> Lowering of `SwitchExpressionOp` and `SwitchStatementOp` into `ConstantLabelSwitchOp` is also a part of this PR.
>> 
>> Lowering of `BreakOp`, `SwitchFallthroughOp` and nested switches will be implemented in a follow-up PR.
>> 
>> This PR also makes minor refinements to the BytecodeGenerator post-processing transformations.
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'asotona/bytecodegenerator-cleanup' into bytecodegenerator-cleanup
>  - Fix JavaSwitchOp.lower to correctly lower regardless of where default case appears

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 2846:

> 2844: 
> 2845:             for (int i = 0; i < bodies().size(); i+=2) {
> 2846:                 if (i == defLabelIndex) {

I was thinking this would break the physical body blocks order, however they are allocated early and the order is correct.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2589292172


More information about the babylon-dev mailing list