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 startup. On the other hand, I heard that there have
been some improvements on the AppCDS w.r.t MethodHandles, but I'm out
of the loop there.
An other problem with completely replacing the native accessors is
some bootstrap problem - if certain flags are set (some of them are
used to build the CDS), then the java.lang.invoke infrastructure tries
to write stuff to System.out. But to initialize System.out, the
charset has to be constructed, which relies on reflection.
I can see some potential in improving the initialization of the
standard charset, but it's out of the scope here.
Apropos scope: I try to narrow the scope down to "replace
MethodAccessorGenerator with accessors that delegate to MethodHandles".
Once this is done, then additional improvements can be made -
including some that take loom into account. Or adding some
@Stable/@ForceInline stuff so the JIT can better optimize reflective
calls.
But currently (didn't look into the loom source) there are only two
strategies: Native accessor (bad for loom) or generated (bytecode
spinning, doesn't work with hidden classes). So, with loom and hidden
classes you get the worst of both worlds. MethodHandles solve that.
As things stands, virtual threads don't call through the VM because of
the potential for blocking with a native trampoline frame on the stack.
The bytecode generator is still used for @CS methods but otherwise it
uses method handles. Hidden classes should be okay although we don't
have tests for that yet. In any case, this will all be replaced once
Mandy's work is further along. Core reflection usages during initPhase2
can be dealt it by deferral until the module system is fully initialized
(as Mandy suggests) as using invoke count would be too fragile. For @CS
methods you will see linked issues where the suggestion to link to an
overloaded method that takes the caller class has been suggested. I also
suspect there will be some C2 work needed.
-Alan
