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

[Paul Sandoz]

On Tue, 2 Dec 2025 14:46: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 one additional commit since the last revision:
> 
>   TestSwitch extended

This is looking good. We should follow up to extract out validating constant expression as per the JLS, and evaluation and place on method of `JavaExpression`.

We likely have some limitations validating and evaluating constant expressions because we rely on reflection to resolve to Fields.

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/impl/LoweringTransform.java line 124:

> 122:             }
> 123:             Op op = opr.op();
> 124:             if (op instanceof CoreOp.ConstantOp cop) {

Change all this to a switch expression.

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/impl/LoweringTransform.java line 140:

> 138:                 Field field;
> 139:                 try {
> 140:                     field = fieldLoadOp.fieldDescriptor().resolveToField(lookup);

Will this work for code that is being compiled as there will be no respective classes loaded? (Perhaps there are clues as to what javac does.)

We might need to provide an abstraction to resolve a reference in the context of the compiler or runtime and query the referenced state.

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/impl/LoweringTransform.java line 156:

> 154:             }
> 155:             if (op instanceof JavaOp.ConditionalExpressionOp cexpr) {
> 156:                 // bodies must yield constant expressions

We need to constrain the last three ops to bodies with just one block. Relying on the cast is too fragile.

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/impl/LoweringTransform.java line 250:

> 248:     }
> 249: 
> 250:     static Integer extractConstantLabel(MethodHandles.Lookup lookup, Body body, Op whenToStop) {

This works and is OK for now, but is a bit of a blunt hammer. Since we are dealing with expressions we should be able to traverse from the root of the constant expression tree.

test/jdk/java/lang/reflect/code/bytecode/TestIsCaseConstantSwitch.java line 30:

> 28: 
> 29:     class C {
> 30:         static final int x = 26;

What about a case label accessing a static field of `TestIsCaseConstantSwitch`?

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

PR Review: https://git.openjdk.org/babylon/pull/706#pullrequestreview-3531342157
PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2582174697
PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2582179055
PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2582181488
PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2582209198
PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2582223589