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
