I now implemented a prototype for JDK-6824466: [1]
The goal I set here was to remove the old AccessorGenerator.
The good news:
- It works - all tier1 tests pass, except one that requires the old
implementation.
- A lot of code has been removed. And even more could be removed.
The bad news:
Thanks Alan.
For using MethodHandles and @CS methods: As far as I remember,
MethodHandle is also skipped on a stack walk for security. In my
prototype (where I did always use MethodHandles for Method.invoke)
MethodHandles.class.findStatic("lookup").invoke(null) did return a
Lookup with the ri
On 01/02/2021 15:19, Johannes Kuhn wrote:
:
Thanks Rémi.
The problem here is that (according to Peter Levart tests), the cold
use of a MHMethodAccessor is 11x as expensive as using the native
accessor.
In some way, it sill makes sense to keep the native accessor around,
at least during sta
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 goa
On 01-Feb-21 15:58, Remi Forax wrote:
- Mail original -
De: "Johannes Kuhn"
À: "core-libs-dev"
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 dynam
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 clunk
- Mail original -
> De: "Johannes Kuhn"
> À: "core-libs-dev"
> 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 ca
