On 08/05/2016 12:56 PM, Aleksey Shipilev wrote:
This looks good to me, Claes.
Thanks!
I wouldn't mind to have a comment at @ForceInline line mentioning this
is for Reflection.getCallerClass() optimization. But, it might be
recoverable from the source control anyway.
Sure, how about:
@ForceInline // to ensure Reflection.getCallerClass optimization
http://cr.openjdk.java.net/~redestad/8161379/jdk.02/
While source control history helps, I think it's alright with some
additional verbiage here in case someone figures out a way to
implement any of these without Reflection.getCallerClass (since
we ideally don't want to @ForceInline in too many places)
/Claes
Thanks,
-Aleksey
On 08/05/2016 10:37 PM, Claes Redestad wrote:
Anyone?
On 07/19/2016 08:16 AM, Claes Redestad wrote:
Hi,
most @CallerSensitive methodscall Reflection.getCallerClass(), which
turn out to have problematic performance characteristics when it fails
to inline.
Making @CallerSensitive imply @ForceInline actually works rather well
across benchmarks, but didn't meet with approval from hotspot-compiler
because it's a hack (unlike @ForceInline /s).
Instead, here is a patch to explicitly @ForceInline those methods where
it can plausibly be helping with performance:
Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8161379
Thanks!
/Claes
