Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic

[Johannes Kuhn]

On 11/23/2019 10:40 PM, Brian Goetz wrote:
>
>>
>> Finally, we can benchmark the current approach against the LDC 
>> approach on a per-Method basis.  The LDC approach may well be doing 
>> more work per Method, so it's a tradeoff to determine whether 
>> deferring that work is a win.
>
> By this last bit, I mean JMH'ing:
>
>     Method m1() {
>        return Class.forName("java.lang.Object").getMethod("equals", 
> new Class[] { Class.forName("java.lang.Object") });
>     }
>
> vs
>
>     Method m2() {
>         return bootstrap(... constant bootstrap args for above ...)
>     }
>
>
Thanks for the pointers, I did run one round on my machine - I don't 
have a dedicated one - so, maybe treat it with a fine grain of salt.
The test code and results can be found here: 
https://gist.github.com/DasBrain/501fd5ac1e2ade2e28347ec666299473

Benchmark                              Mode  Cnt Score        Error  Units
ProxyFindMethod.getMethod             thrpt   25  1505594.515 ± 
42238.663  ops/s
ProxyFindMethod.lookupMethod          thrpt   25   760530.602 ± 
25074.003  ops/s
ProxyFindMethod.lookupMethodCachedMH  thrpt   25  4327814.284 ± 
103456.616  ops/s

I wrote three tests, the first one (getMethod) uses the 
Class.forName().getMethod(), the second uses lookup.findVirtual to get 
the MethodHandle every iteration, while the third one caches it in a 
static final field.

My interpretation: If the method has to be looked up (and the VM has to 
do that at least once), then the old getMethod call is faster.
I also suspect the Class.forName call to be optimized - on some old java 
versions, iirc pre-1.5, Foo.class was compiled into 
Class.forName("Foo"), so the JIT might do something there.
So, now I have to learn how to read assembly. Good.