JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle

[Johannes Kuhn]

Thanks Mandy.

Yes, the 3 prototypes I mentioned were yours, Peter Levart's, and my own.
(My prototype is at 
https://github.com/DasBrain/jdk/tree/reflection-MHaccessors - I hit an 
boostrap problem, build a workaround that I don't really like, so I 
stopped working on that.)

I agree on your goals, they are the same as mine.

For the constructor story, well, that is a prerequisite for the hidden 
proxy classes. I'll take an other look at your implementation, and maybe 
open a pull request against your repo.

Current approach is to keep the scope small - just replacing the old 
generated accessors with method handle based ones.

Even this "small" change is IMHO worthwhile:

* Getting rid of the old MethodAccessorGenerator (I don't want to 
maintain it, and if I had to, then moving to ASM would be a step forward)
* Better performance on calling methods from hidden classes. (Loom 
doesn't like native frames on the stack)
* Prerequisite for further enchantments, such as hidden proxy classes, 
alternatives for reflective @CS and possible performance improvements 
using @Stable/@ForceInline.

It's just - it's an old bug, and other people already did try some stuff 
on it. So I try to learn from their experience and try to understand 
what roadblocks they hit first. No need to repeat the mistakes others 
already made.

- Johannes

On 01-Feb-21 18:37, Mandy Chung wrote:
> Hi Johannes,
> 
> I believe you are aware of the prototype I'm working on:
> https://github.com/mlchung/jdk/tree/method-invoke
> 
> My prototype so far replaces method and fields but not constructors 
> yet.   You are welcome to contribute.
> 
> My main motivation of doing this is to get rid of the old clunky 
> bytecode generator and core reflection will be built atop on method 
> handles.   This would greatly simplify the work to add support for a new 
> feature for example Valhalla primitive classes only in method handles.  
>    I plan to keep the native method accessor  for startup use (or switch 
> to method handles when module system is initialized).
> 
> Mandy
> 
> On 2/1/21 6:50 AM, Johannes Kuhn wrote:
>> While implementing a prototype for JDK-8242888 (Convert dynamic proxy 
>> to hidden classes) I came across the problem that hidden classes can't 
>> be mentioned in the constant pool, breaking the constructor for 
>> serialization.
>>
>> To remedy that problem, I used a MHConstructorAccessor which delegates 
>> the actual work to MethodHandles - not unlike what JDK-6824466 suggests.
>>
>> As there has been previous work in that area, (I am aware of at least 
>> 3 independently developed prototypes for that bug/enchantment) I would 
>> like to ask a few questions around it:
>>
>>
>>
>> 1) What are the challenges?
>>
>> From the bug I could infer, that it's cold start is slower than 
>> NativeMethodAccessor, but still faster than the generated (bytecode 
>> spinning) accessors.
>>
>> 2) Are there any roadblocks that prevent replacing the 
>> MethodAccessorGenerator with accessors that use MethodHandles?
>>
>> From my limited tests, it appears to work well enough.
>>
>> 3) Should I try to implement it?
>>
>>
>>
>> From my POV, replacing MethodAccessorGenerator with accessors that 
>> delegate to MethodHandles has a few benefits:
>>
>> * Support for hidden classes. (Currently fallback to native accessors)
>> * Removal of MethodAccessorGenerator (which is old and clunky)
>>
>> - Johannes
>