UserAccessorProperty caching prevents HotSpot from profiling MethodHandles, sinking box2d performance through lack of inlining

Box2d is very user getter/setter prone.

I don't really understand why we have that dynamic invoker wrapping mechanism - it's been with us since time immemorial in UserAccessorProperty - can someone entlighten me?

Anyway this seems to be worth plenty of performance.

Vladimir says
--

And lambdaform code that never really has a chance to be properly optimized - sometimes just simply because the JIT stops inlining, or sometimes because java.lang.invoke is full of boxing and arraycopies that simple don’t go away.
If you have any info about any of those problems, please, file a bug/let me know. I'll be happy to fix them.

Sergey Kuksenko had a very interesting performance analysis presentation at JVMLS this year where ~41% of his runtime for Nashorn with octane.box2d was unlined lambda forms.
I already told you in private, but just to let others know.
The reason why there's an uninlined LambdaForm call in Box2D is because Nashorn does MH caching itself (see [1]).

HotSpot can't see through the cache and it doesn't do value profiling of receiver for MethodHandle.invoke*(), so inlining fails.

Roland experimented with receiver profiling for MethodHandle.invoke* support, but I'm not aware about any plans to integrate it into the product.

Best regards,
Vladimir Ivanov

[1] nashorn.internal.runtime.UserAccessorProperty.userAccessorGetter
   nashorn.internal.runtime.UserAccessorProperty.userAccessorSetter

http://hg.openjdk.java.net/jdk9/jdk9/nashorn/file/adc2b63e654a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java#l276