Trying to understand performance of MethodHandles and LambdaForms in 8u60 (original) (raw)
Christopher Berner christopherberner at gmail.com
Fri Oct 30 17:51:44 UTC 2015
- Previous message: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS
- Next message: RFR 8140685: Fix backtrace building to not rely on constant pool merging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I discovered that jdk 8u60 does a lot of optimizations of MethodHandles that I didn't expect, so I'm trying to understand what I can expect the VM to optimize now.
I created this JMH benchmark ( https://gist.github.com/cberner/c141e651cb45288fba24) which tests various ways of implementing a simple loop.
On 8u40 (https://gist.github.com/cberner/ec8039d1fd972568fe88), the results show that only the "fast" version, where it's invoking a single static method, reaches the peak performance.
However, with 8u60 (https://gist.github.com/cberner/b5de95e68e2ba2aa7ca2), the performance is very different.
How does the "boundInvokeExact" version now reach peak performance? (which uses bindTo to combine the inner part of the loop and the outer part) Is it that LambdaForms now have extra profiling information, and bindTo creates a new LambdaForm? I note that the "localBoundInvokeExact" version is also pretty fast now.
Why is the "invokeExact" version faster than the "invokeStatic" version? I'm quite surprised that getting a MethodHandle to a static method and then invoking it is faster than just invoking the static method.
Why are "multipleInvokeStatic" and "multipleInvokeExact" so slow? I expected these to be easier to optimize than "boundInvokeExact".
Thanks in advance for any insights! Christopher
- Previous message: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS
- Next message: RFR 8140685: Fix backtrace building to not rely on constant pool merging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]