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

[Remi Forax]

----- Mail original -----
> De: "Johannes Kuhn" <info at j-kuhn.de>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 1 Février 2021 15:50:51
> Objet: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle

> 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)

Hi Johannes,
the native accessors doesn't play with loom (a C stack frame in the middle of the Java stack can not be moved) so it doesn't seem to be a good idea to rely on the native accessors for hidden classes.

> 
> - Johannes

Rémi