[code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]

[Paul Sandoz]

On Wed, 18 Sep 2024 07:10:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 150:
>> 
>>> 148:                 }
>>> 149:             } catch (UnsupportedOperationException uoe) {
>>> 150:                 // InvokeSuperOp
>> 
>> Is this related to bytecode instructions for construction not conforming to an expected shape?
>
> I understand relation between `invokespecial` and `InvokeSuperOp` introduced in #221 following way:
> - We cannot simply generate `invokespecial` from `InvokeSuperOp` for reasons mentioned in the `BytecodeGenerator` and so we throw `UnsupportedOperationException` for now.
> - We generate `invokespecial` from `NewOp` of a non-array type.
> - When `invokespecial` of `<init>` method name follows `new` of the type equals the `invokespecial` owner, it is lifted as `NewOp` of the given non-array type.
> - However all other `invokespecial` instructions suppose to be lifted as `InvokeSuperOp`? 
> 
> I made this assumption and changed `BytecodeLift` of `invokespecial` to lift into`InvokeSuperOp`, which caused certain amount of `TestSmallCorpus` to throw `UnsupportedOperationException`. 
> Please confirm the assumption is correct.

Ok, i see now. Your assumptions are correct.
(Note #225 lumps `InvokeSuperOp` into `InvokeOp` but it does not change the assumptions.)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/228#discussion_r1765432426