On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati <d...@openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code 
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, 
>> MethodType, and CallSite constants.
>> ### Purpose of Indify
>> 
>> -  **Transformation Tool**: `Indify` transforms existing class files to 
>> leverage `invokedynamic` and other JSR 292 features. This transformation 
>> allows for dynamic method calls.
>> 
>> ### Key Functions
>> 
>> - **Method Handle and Method Type Constants**:
>>     - **MH_x and MT_x Methods**: These methods are used to generate 
>> `MethodHandle` and `MethodType` constants. The tool transforms calls to 
>> these methods into `CONSTANT_MethodHandle` and `CONSTANT_MethodType` "ldc" 
>> (load constant) instructions.
>> -  **Invokedynamic Call Sites**:
>>     - **INDY_x Methods**: These methods generate `invokedynamic` call sites. 
>> Each `INDY_x` method starts with a call to an `MH_x` method, which acts as 
>> the bootstrap method. This is followed by an `invokeExact` call.
>>     - **Transformation**: The tool transforms pairs of calls (to `INDY_x` 
>> followed by `invokeExact`) into `invokedynamic` instructions. This mimics 
>> the JVM's handling of `invokedynamic` instructions, creating dynamic call 
>> sites that are linked at runtime.
>> 
>> It currently uses ad-hoc code to process class files and intends to migrate 
>> to ASM; but since we have the Classfile API, we can migrate to Classfile API 
>> instead.
>
> Oussama Louati has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove: removed unnecessary logging

Unfortunately this pull request is not converging to an acceptable state.

Core transformation should be designed  from top to down, with understanding of 
the functionality and with respect to Class-File API architecture. Currently 
proposed implementation is confusing mix of the original code, glued together 
with fragments of Class-File API.

The patch also contains many cosmetic changes and unrelated semantic changes 
making the patch very hard to read.

The PR could not be finished just by requesting reviewers attention and partly 
reflecting their suggestions, it should be significantly re-designed.

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

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2138609501

Reply via email to